This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: PR other/55333: libsanitizer StackTrace::FastUnwindStack wrong x32
I am sensing some optimization here :) Is it really important to
collect the full stack trace for the allocation context? You care
about actual site where the allocation happens -- which might usually
be the calls to the malloc like wrappers. The distance from there to
the leaf should not he too far, right?
David
On Thu, Nov 15, 2012 at 9:36 AM, Konstantin Serebryany
<konstantin.s.serebryany@gmail.com> wrote:
> On Thu, Nov 15, 2012 at 9:25 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
>> On Thu, Nov 15, 2012 at 9:19 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>>> On Thu, Nov 15, 2012 at 09:05:13AM -0800, Konstantin Serebryany wrote:
>>>> +dvyukov, +glider, +samsonov
>>>>
>>>> Sorry I am lagging behind e-mail, but I am sure Dmitry, Alexander or
>>>> Alexey may submit the patch upstream.
>>>> Please make sure to comment the reason for using a separate typedef.
>>>>
>>>> We need our custom unwinder based on frame pointers to remain the
>>>> default choice on x86[_64] because this is a hotspot
>>>> and replacing it with any library call (especially if that call does
>>>> not use frame pointers but instead uses debug info) will slow down
>>>> the tool significantly.
>>>> The asan docs explicitly say that you need -fno-omit-frame-pointers to
>>>> get reasonable bug reports.
>>>
>>> The backtrace at asan crash time definitely isn't a hotspot, so that IMHO is
>>> a place which definitely should use a proper and accurrate library
>>> unwinding.
>>
>> Asan collects stack traces on every malloc/free call.
>
> Right.
> A simple exercise: run 400.perlbench or 483.xalancbmk with asan.
> If the stack traces in malloc/free are enabled (which is the default),
> they consume 10-30% of time (don't remember the exact numbers).
> If we replace fp-based unwinder with something else, this will become 80%.
> Most programs we care about (e.g. Chrome or Firefox) behave very
> similar to 483.xalancbmk, i.e. they are very malloc intensive and have
> deep calls stacks.
>
> --kcc
>
>>
>>
>>> Frame pointers aren't emitted by default on either x86_64 or
>>> i?86, system libraries likely won't have them, unless people rebuild
>>> everything with -fsanitize=address -fno-omit-frame-pointer (unlikely to
>>> happen) etc. So relying on frame pointers is definitely very risky.
>>
>> If a user has asan build where he adds -fsanitize=address, it seems
>> trivial to add -fno-omit-frame-pointer as well.
>>
>>> Even
>>> libasan itself is right now built with, even explicit, -fomit-frame-pointer.
>>
>> That's the right thing. Asan does not unwind itself and performance critical.