Re: [google gcc-4_7, integration] Build more of libstdc++ with frame pointers

[Andrew Pinski <pinskia at gmail dot com>]

On Wed, Feb 27, 2013 at 12:53 PM, Jeff Law <law@redhat.com> wrote:
> On 02/27/2013 01:50 PM, Paul Pluzhnikov wrote:
>>
>> On Wed, Feb 27, 2013 at 12:17 PM, Andrew Pinski <pinskia@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