Gprof .so file

If you take a look at gcc's man page, here's what it says about the -pg option:. You must use this option when compiling the source files you want data about, and you must also use it when linking. The next step is to launch that executable. Here's how I launched the binary in my case:. Once the command is executed, you'll see that a file named gmon.

It is this file which contains all the information that the Gprof tool requires to produce a human-readable profiling data. So, now use the Gprof tool in the following way:. Now, before we see the information the profile-data. Here's what the man page of Gprof says about information under these two sections:. If you simply want to know which functions burn most of the cycles, it is stated concisely here. There is also an estimate of how much time was spent in the subroutines of each function.

This can suggest places where you might try to eliminate function calls that use a lot of time. Armed with this information, now you'll be in a better position to understand the data present in your profiling output file profile-data. Here's the flat profile in my case:.

If you're wondering about the source of above screenshots, let me tell you that all this information is there in the output file that contains the profiling information, including flat profile and call graph. In case you want this information to be omitted from the output, you can use the -b option provided by Gprof. Needless to say, we've just scratched the surface here, as Gprof offers a lot of features just take a look at its man page.

However, whatever we've covered here should be enough to get you started. In case you already use Gprof, and want to share something related to the tool with everyone here, just drop in a comment below.

I have repeated same procedure with my code using gprof but each time in text file is zero inspite of calling function many time. Great article! In this program, all the time spent in foo is in the calls from callers other than a. But gprof has no way of knowing this; it will blindly and incorrectly charge 2 seconds of time in foo to the children of a.

For the nonce, the estimated figures are usually more useful than misleading. But there are a few differences. Profiling works by changing how every function in your program is compiled so that when it is called, it will stash away some information about where it was called from.

From this, the profiler can figure out what function called it, and can count how many times it was called. The mcount routine, included in the profiling library, is responsible for recording in an in-memory call graph table both its parent routine the child and its parent's parent. This is typically done by examining the stack frame to find both the address of the child, and the return address in the original parent.

However, on some architectures, most notably the SPARC, using this builtin can be very computationally expensive, and an assembly language version of mcount is used for performance reasons. Number-of-calls information for library routines is collected by using a special version of the C library. Profiling also involves watching your program as it runs, and keeping a histogram of where the program counter happens to be every now and then. Typically the program counter is looked at around times per second of run time, but the exact frequency may vary from system to system.

This is done is one of two ways. Most UNIX-like operating systems provide a profil system call, which registers a memory array with the kernel, along with a scale factor that determines how the program's address space maps into the array. Typical scaling values cause every 2 to 8 bytes of address space to map into a single array slot. On every tick of the system clock assuming the profiled program is running , the value of the program counter is examined and the corresponding slot in the memory array is incremented.

Since this is done in the kernel, which had to interrupt the process anyway to handle the clock interrupt, very little additional system overhead is required. However, some operating systems, most notably Linux 2. On such a system, arrangements are made for the kernel to periodically deliver a signal to the process typically via setitimer , which then performs the same operation of examining the program counter and incrementing a slot in the memory array.

Since this method requires a signal to be delivered to user space every time a sample is taken, it uses considerably more overhead than kernel-based profiling. Also, due to the added delay required to deliver the signal, this method is less accurate as well.

A special startup routine allocates memory for the histogram and either calls profil or sets up a clock signal handler. This routine monstartup can be invoked in several ways. On Linux systems, a special profiling startup file gcrt0. Rather, the mcount routine, when it is invoked for the first time typically when main is called , calls monstartup. Each object file is then compiled with a static array of counts, initially zero. In the executable code, every time a new basic-block begins i.

At compile time, a paired array was constructed that recorded the starting address of each basic-block. Taken together, the two arrays record the starting address of every basic-block, along with the number of times it was executed.

Profiling is turned off, various headers are output, and the histogram is written, followed by the call-graph arcs and the basic-block counts. This is because samples of the program counter are taken at fixed intervals of the program's run time. Therefore, the time measurements in gprof output say nothing about time that your program was not running.

For example, a part of the program that creates so much data that it cannot all fit in physical memory at once may run very slowly due to thrashing, but gprof will say it uses little time. On the other hand, sampling by run time has the advantage that the amount of load due to other users won't directly affect the output you get.

The old BSD-derived file format used for profile data does not contain a magic cookie that allows to check whether a data file really is a gprof file. Furthermore, it does not provide a version number, thus rendering changes to the file format almost impossible. GNU gprof uses a new file format that provides these features. For backward compatibility, GNU gprof continues to support the old BSD-derived format, but not all features are supported with it.

For example, basic-block execution counts cannot be accommodated by the old file format. It consists of a header containing the magic cookie and a version number, as well as some spare bytes available for future extensions. All data in a profile data file is in the native format of the host on which the profile was collected.

GNU gprof adapts automatically to the byte-order in use. In the new file format, the header is followed by a sequence of records. Currently, there are three different record types: histogram records, call-graph arc records, and basic-block execution count records. Each file can contain any number of each record type. When reading a file, GNU gprof will ensure records of the same type are compatible with each other and compute the union of all records.

For example, for basic-block execution counts, the union is simply the sum of all execution counts for each basic-block. Histogram records consist of a header that is followed by an array of bins. The header contains the text-segment range that the histogram spans, the size of the histogram in bytes unlike in the old BSD format, this does not include the size of the header , the rate of the profiling clock, and the physical dimension that the bin counts represent after being scaled by the profiling clock rate.

The physical dimension is specified in two parts: a long name of up to 15 characters and a single character abbreviation. For example, a histogram representing real-time would specify the long name as "seconds" and the abbreviation as "s". This feature is useful for architectures that support performance monitor hardware which, fortunately, is becoming increasingly common. In this case, the dimension in the histogram header could be set to "i-cache misses" and the abbreviation could be set to "1" because it is simply a count, not a physical dimension.

Also, the profiling rate would have to be set to 1 in this case. Histogram bins are bit numbers and each bin represent an equal amount of text-space. For example, if the text-segment is one thousand bytes long and if there are ten bins in the histogram, each bin represents one hundred bytes. Call-graph records have a format that is identical to the one used in the BSD-derived file format. It consists of an arc in the call graph and a count indicating the number of times the arc was traversed during program execution.

Arcs are specified by a pair of addresses: the first must be within caller's function and the second must be within the callee's function. When performing profiling at the function level, these addresses can point anywhere within the respective function. This will ensure that the line-level call-graph is able to identify exactly which line of source code performed calls to a function. The header simply specifies the length of the sequence. Any address within the basic-address can be used.

Like most programs, gprof begins by processing its options. Next, the BFD library is called to open the object file, verify that it is an object file, and read its symbol table core. For normal profiling, the BFD canonical symbol table is scanned. For line-by-line profiling, every text space address is examined, and a new symbol table entry gets created every time the line number changes.

In either case, two passes are made through the symbol table - one to count the size of the symbol table required, and the other to actually read the symbols. In between the two passes, a single array of type Sym is created of the appropiate length. Finally, symtab. The symbol table must be a contiguous array for two reasons. First, the qsort library function which sorts an array will be used to sort the symbol table.

Also, the symbol lookup routine symtab. Line number symbols have no special flags set. Remember that a single symspec can match multiple symbols. An array of symbol tables syms is created, each entry of which is a symbol table of Syms to be included or excluded from a particular listing.

The master symbol table and the symspecs are examined by nested loops, and every symbol that matches a symspec is inserted into the appropriate syms table. This is done twice, once to count the size of each required symbol table, and again to build the tables, which have been malloced between passes. From now on, to determine whether a symbol is on an include or exclude symspec list, gprof simply uses its standard symbol lookup routine on the appropriate table in the syms array.

New-style histogram records are read by hist. For the first histogram record, allocate a memory array to hold all the bins, and read them in. When multiple profile data files or files with multiple histogram records are read, the starting address, ending address, number of bins and sampling rate must match between the various histograms, or a fatal error will result.

If everything matches, just sum the additional histograms into the existing in-memory array. As each arc is added, a linked list is maintained of the parent's child arcs, and of the child's parent arcs. Both the child's call count and the arc's call count are incremented by the record's call count.

Again, if multiple basic-block records are present for the same address, the call counts are cumulative. This file contains two tables: flat profile: overview of the timing information of the functions call graph: focuses on each function -b option will suppress lot of verbose information which would be otherwise included in analysis file.

Eduonix Learning Solutions. Frahaan Hussain. Pradeep D. Musab Zayadneh. Previous Page. Next Page. Useful Video Courses. More Detail. Essentials of Unix Operating System 5 Lectures 4. Unix and Linux Training 6 Lectures 4 hours Uplatz. Previous Page Print Page. Save Close. The -A option causes gprof to print annotated source code.

The -C option causes gprof to print a tally of functions and the number of times each was called. The -i option causes gprof to display summary information about the profile data file s and then exit. The -I option specifies a list of search directories in which to find source files. The -J option causes gprof not to print annotated source code. Normally, source filenames are printed with the path component suppressed. The -p option causes gprof to print a flat profile. The -P option causes gprof to suppress printing a flat profile.

The -q option causes gprof to print the call graph analysis. The -Q option causes gprof to suppress printing the call graph. The -t option causes the num most active source lines in each source file to be listed when source annotation is enabled. This option affects annotated source output only. The -Z option causes gprof not to print a tally of functions and the number of times each was called. The --function-ordering option causes gprof to print a suggested function ordering for the program based on profiling data.

The --file-ordering option causes gprof to print a suggested. The -T option causes gprof to print its output in traditional BSD style. Sets width of output lines to width. The -a option causes gprof to suppress the printing of statically declared private functions. The -c option causes the call graph of the program to be augmented by a heuristic which examines the text space of the object file and identifies function calls in the binary machine code.

The -D option causes gprof to ignore symbols which are not known to be functions. The -k option allows you to delete from the call graph any arcs from symbols matching symspec from to those matching symspec to.