Finding a profiler that works, damnit [LWN.net]

Finding a profiler that works, damnit

Posted Mar 24, 2010 8:10 UTC (Wed) by ringerc (subscriber, #3071)
In reply to: Finding a profiler that works, damnit by foom
Parent article: KVM, QEMU, and kernel project management

gprof: Old standby -- I used to use this all the time back in the day... Unfortunately, only works on staticly linked programs.

gprof works fine on dynamically linked programs. In fact, it's awfully rare to find a genuinely statically linked program these days - most "static" programs dynamically link to libc via ld-linux.so and statically link in all the other libraries they use, as ldd will reveal. Not always, but usually.

I suspect what you were going for was "gprof only profiles one particular library or executable at a time, not a whole program including any shared libraries or plugins it uses." (Even that's not strictly true, it's just that you have to rebuild those plugins or shared libraries with gprof instrumentation too).

I'm totally with you on the general "argh" re callgraph profiling across multiple programs or a subset of the system, though.

(Log in to post comments)

Finding a profiler that works, damnit

Posted Mar 24, 2010 15:05 UTC (Wed) by foom (subscriber, #14868) [Link]

> Even that's not strictly true, it's just that you have to rebuild those plugins or shared libraries
> with gprof instrumentation too.

No, gprof really just doesn't work at all with shared libraries. If you link an executable with -pg,
you'll only get samples from when the PC is inside the base executable. Any times the timer tick
goes off when the PC is in another location, it's simply ignored. This is true even if you did
compile all libraries with -pg too.

So if you do run gprof with dynamically linked executable, your timing measures will all be
wrong, if you spend any time whatsoever inside shared libraries. E.g. I was profiling a program
where it turned out 1/4 the time was spent in libc and libstdc++ (shouldn't have been that
much..but that's what the profiler is for!). But using gprof, that time simply disappears, it's like
those functions took no time whatsoever even in the "inclusive" measures of higher level
functions that *are* in the executable. And the total run-time is also reported to be much
smaller than it actually is.