This is the mail archive of the
mailing list for the GCC project.
Re: [google gcc-4_7, integration] Build more of libstdc++ with frame pointers
On Wed, Feb 27, 2013 at 12:53 PM, Jeff Law <firstname.lastname@example.org> wrote:
> On 02/27/2013 01:50 PM, Paul Pluzhnikov wrote:
>> On Wed, Feb 27, 2013 at 12:17 PM, Andrew Pinski <email@example.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
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.