| |||||||||||||
Finding a profiler that works, damnitFinding a profiler that works, damnitPosted Mar 24, 2010 1:11 UTC (Wed) by nix (subscriber, #2304)In reply to: Finding a profiler that works, damnit by chantecode Parent article: KVM, QEMU, and kernel project management
Sure, how could it be another way? Without frame pointers you can't have reliable stacktraces.GDB has been able to use DWARF2 information to produce stack traces without frame pointers for many releases now.
(Log in to post comments)
Finding a profiler that works, damnit Posted Mar 24, 2010 1:25 UTC (Wed) by HelloWorld (guest, #56129) [Link]
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.
Finding a profiler that works, damnit Posted Mar 24, 2010 3:12 UTC (Wed) by joseph.h.garvin (subscriber, #64486) [Link]
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]
... 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...
Finding a profiler that works, damnit Posted Mar 25, 2010 4:23 UTC (Thu) by adsharma (subscriber, #8967) [Link]
libunwind supports multiple architectures and can unwind without frame
|
|||||||||||||