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

[Evgeniy Stepanov]

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.

>
> 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?

>
>
> http://reviews.llvm.org/D9259
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>