[PATCH, RFC] Enable libsanitizer on powerpc{,64}

Evgeniy Stepanov eugeni.stepanov@gmail.com
Tue Nov 20 15:12:00 GMT 2012


Ok, fine.


On Tue, Nov 20, 2012 at 6:47 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Tue, Nov 20, 2012 at 6:21 PM, Konstantin Serebryany
> <konstantin.s.serebryany@gmail.com> wrote:
>> On Tue, Nov 20, 2012 at 6:18 PM, Evgeniy Stepanov
>> <eugeni.stepanov@gmail.com> wrote:
>>> On Tue, Nov 20, 2012 at 5:52 PM, Konstantin Serebryany
>>> <konstantin.s.serebryany@gmail.com> wrote:
>>>>
>>>> On Tue, Nov 20, 2012 at 5:41 PM, Peter Bergner <bergner@vnet.ibm.com>
>>>> wrote:
>>>> > On Tue, 2012-11-20 at 11:07 +0400, Konstantin Serebryany wrote:
>>>> >> I've applied your patch (with minor style and comment changes)
>>>> >> upstream:
>>>> >> http://llvm.org/viewvc/llvm-project?view=rev&revision=168356
>>>> >> I did not have any way to test it though. Also, gmail does something
>>>> >> horrible with patches inlined in a message, so I might have missed
>>>> >> something.
>>>> >
>>>> > Doing a quick peruse through your LLVM commit, I see you grabbed the
>>>> > PopStackFrames() addition, but the asan_linux.cc changes do not include
>>>> > the call to PopStackFrames() after the _Unwind_Backtrace() call.
>>>> > Specifically, the following patch hunk:
>>>> >
>>>> >>      _Unwind_Backtrace(Unwind_Trace, stack);
>>>> >> > +    // Pop off the two ASAN functions from the backtrace.
>>>> >> > +    stack->PopStackFrames(2);
>>>
>>>
>>> I wonder if under some conditions we may get a different number of extra
>>> frames (inlining comes to mind). What do you think of removing any number of
>>> frames that belong to the runtime library - we have memory layout info for
>>> that?
>>
>> Bad idea, imho.
>> Hard to implement, slower to run (remember, this *is* a hotspot).
>> The frames in question are in our run-time and we can fully control inlining.
>> What is the current number of redundant frames on ARM?
>
>
> And we can have output tests that verify that we remove the right
> number of frames.



More information about the Gcc-patches mailing list