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

[Bill Seurer]

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.

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.


http://reviews.llvm.org/D9259

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