This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: gprof Observations
- From: Segher Boessenkool <segher at koffie dot nl>
- To: "Bhattacharya, Soubhik" <soubhik_bhattacharya at mentorg dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Sat, 05 Jul 2003 15:46:24 +0200
- Subject: Re: gprof Observations
- References: <3F042291.4010403@mentorg.com>
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