gprof Observations

[Segher Boessenkool]

Bhattacharya, Soubhik wrote:
> 1. if a function `foo()' is not compiled with -pg then gprof fails to 
> determine the callers of and no. of calls to `foo()'. however, if 
> `foo()' runs long enuff then it reliably estimates its self-time.

Compiling a unit with -pg causes GCC to add a preamble to
every function, that does reference counting etc.

> 2. using -pg during linking ensures that the program is linked with a 
> special gprof specific start file. this is the minimum requirement for 
> gprof to be able to generate some useful information (a flat profile).

This start file calls monstartup(); you can call it yourself,
too, if you prefer.

> 3. gprof fails to gather profiling info (self-time, no. of calls, 
> calling functions) of a function residing in a shared object. any 
> suggestion? i searched the net to find a couple of mails on a similar 
> topic (http://mail.gnu.org/archive/html/bug-gnu-utils/2001-07/msg00284.html
> http://sources.redhat.com/ml/binutils/2003-03/msg00208.html), which, 
> sadly, went unanswered.

monstartup() etc. can handle only one VM range; the gmon.out
file format can't handle multiple ranges either, iirc.

> if obs 3. is correct, it shud be considered a serious limitation, 
> restricting gprof's usefulness in modern software engineering.

You can try profiling a statically linked executable.
Dynamically loaded objects won't work; but those are a
separate problem for profiling, anyway.


Segher