On Wed, Feb 27, 2013 at 12:53 PM, Jeff Law <l...@redhat.com> wrote: > On 02/27/2013 01:50 PM, Paul Pluzhnikov wrote: >> >> On Wed, Feb 27, 2013 at 12:17 PM, Andrew Pinski <pins...@gmail.com> wrote: >> >>> Just an aside which program does not understand dwarf2 unwinding? >> >> >> All Google executables currently link in a frame-based unwinder. >> >> This allows us to report crashes and record runtime statistics from the >> executable itself, in ways that are convenient when dealing with thousands >> of executables spread across millions of machines, and which are much >> harder to achieve using external tools. >> >> There is of course libunwind, but it turns out that it's very hard to >> beat speed and simplicity of a frame-based unwinder (which matters when >> you collect stack traces across live production services).
libunwind is not needed since there is already a dwarf2 based unwinder that is accessible in libgcc already. I don't know why people still promote libunwind when libgcc already has similar facilities. >> >> I hope this answers your question. > > Or imagine something like trying to get traces out of low level profilers > and such. There are situations where dwarf2 unwinders are just too damn > bloated. Perf handles this by saving off some of the stack space instead and then post-process it. This is why I said perf handles this case already. Now oprofile does not but oprofile is really going away. Thanks, Andrew > > jeff
