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

Finding a profiler that works, damnit

Posted Mar 24, 2010 1:25 UTC (Wed) by HelloWorld (guest, #56129)
In reply to: Finding a profiler that works, damnit by nix
Parent article: KVM, QEMU, and kernel project management

How does that help? The problem seems to be that one has to recompile a lot of stuff in order to get stack traces. You have to recompile in order to get dwarf2 debugging information too.

to post comments

Finding a profiler that works, damnit

Posted Mar 24, 2010 3:12 UTC (Wed) by joseph.h.garvin (subscriber, #64486) [Link] (2 responses)

It's slightly more usable, because people are usually doing debug builds already, but not -fno-omit-frame-pointer builds. It's also not uncommon to release optimized builds with debug symbols to make cores easier to understand in the wild.

Finding a profiler that works, damnit

Posted Mar 24, 2010 8:12 UTC (Wed) by ringerc (subscriber, #3071) [Link] (1 responses)

... and often those debug symbols are included as separate -dbg or -debug packages in the package management system, so if your tool knows how to read gdb external debug symbol files, you get to use the original binaries AND get debug info.

Of course, many profiling tools don't know about external debuginfo files...

Finding a profiler that works, damnit

Posted Mar 24, 2010 10:31 UTC (Wed) by nix (subscriber, #2304) [Link]

Virtually everything that reads debugging information knows how to use external debug files, both in /usr/lib/debug/$PATH.dbg format and in /usr/lib/debug/$BUILD_ID format, because both of these have been used by widely-released distributions (Ubuntu and Red Hat have both used various versions of these).

It's been some years since I've come across any tool that reads DWARF2 that doesn't know about at least one of these, and in the last year or so everything has learnt about both (including perf).

Since pretty much every distribution is now compiling everything with separated debugging information, anything that doesn't support it isn't going to be particularly useful.

Outside rare code (e.g. the occasional garbage collector) that actually needs frame pointers for correct operation, -fno-omit-frame-pointer is needless, and using -fomit-frame-pointer instead gives a substantial speedup on many common platforms. IIRC it's the default on x86-64, but I don't have a recent GCC source tree here so I can't be sure...