[PATCH] [PowerPC]Adapt fast stack unwinding to work for Power.

[Bill Seurer]

On 06/05/2015 01:39 PM, Evgeniy Stepanov wrote:
> On Fri, Jun 5, 2015 at 8:01 AM, Bill Seurer <seurer at linux.vnet.ibm.com> wrote:
>> I did some additional investigation on this.
>>
>> The "second" copy of the calling function that appears on the stack ("new" and "delete" above) are caused by the code on lines 73 and 74 of sanitizer_stacktrace.cc.
>>
>> trace_buffer[0] = pc;
>>   size = 1;
>>
>> That can be avoided but I am not sure if it is necessary for other platforms and in any case it still works as-is.
>>
>> With that bit of code removed
>>
>> //  trace_buffer[0] = pc;
>>
>>    size = 0;
>>
>> then the trace comes out as
>>
>>    #0 0x10104888 in __asan::GetStackTraceWithPcBpAndContext(__sanitizer::BufferedStackTrace*, unsigned long, unsigned long, unsigned long, void*, bool) /home/seurer/llvm/llvm-test/projects/compiler-rt/lib/asan/asan_stack.h:50
>>    #1 0x10104888 in operator delete(void*) /home/seurer/llvm/llvm-test/projects/compiler-rt/lib/asan/asan_new_delete.cc:94
>>    #2 0x10106fb4 in main (/home/seurer/test/stack/crash-small+0x10106fb4)
>>    #3 0x3fffa9ab4dfc  (/lib/powerpc64le-linux-gnu/libc.so.6+0x24dfc)
>>    #4 0x3fffa9ab4ff0 in __libc_start_main (/lib/powerpc64le-linux-gnu/libc.so.6+0x24ff0)
>>
>> The question is where does __asan::GetStackTraceWithPcBpAndContext come from?
>>
>> I looked through the inliner output and it shows that GetStackTraceWithPcBpAndContext is being inlined.  I also stepped through the compiled code in the debugger and it too shows it was inlined.  Note that GetStackTraceWithPcBpAndContext and operator delete show the same address (0x10104888) above in the trace which is weird.
>
> This is exactly because it is inlined. Try ASAN_OPTIONS=symbolize=0 to
> see the actual unwinder output.

Earlier you had asked if "ALWAYS_INLINE on 
GetStackTraceWithPcBpAndContext did not have any effect" so I checked to 
see if it truly was inlined.

>>
>> So something odd is going on (in the debugger maybe?) but the same thing happens with the slow unwinder too.  That is maybe something that can be investigated but it doesn't really affect this code which is written to match what the slow unwinder does.
>
> The slow unwinder has the extra frames because it starts unwinding
> from the calling function. The fast unwinder starts at the caller of
> "operator new()". Their code should not match.
>
> Also, unless I misunderstand, one your earlier messages (after "On x86
> with the stack popping (the code as-is):") seems to suggest that this
> code breaks x86 tests?

No, this change doesn't affect X86.

My comment was about when I tried disabling the popping of extra frames 
on X86 to see what it was actually popping because it too uses the "pop 
the stack until you get to PC" code in the fast unwinder.
-- 

-Bill Seurer