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

Evgeniy Stepanov eugenis at google.com
Mon May 18 10:45:28 PDT 2015


This is unexpected. Reading the code, operator new() does
GET_STACK_TRACE_MALLOC, which grabs the current PC (though
__builtin_return_address) and frame address (__builtin_frame_address)
and starts frame pointer-based unwind from there.

  #0 0x100ec5d4 in operator new(unsigned long)

/home/seurer/llvm/llvm-test/projects/compiler-rt/lib/asan/asan_new_delete.cc:62:35

  #1 0x100ec668 in GetStackTraceWithPcBpAndContext

/home/seurer/llvm/llvm-test/projects/compiler-rt/lib/asan/asan_stack.h:50:7

  #2 0x100ec668 in operator new(unsigned long)

/home/seurer/llvm/llvm-test/projects/compiler-rt/lib/asan/asan_new_delete.cc:62

  #3 0x100ef274 in main /home/seurer/test/stack/crash.cpp:60:8
  #4 0x3fffa9574cfc in generic_start_main

/build/buildd/eglibc-2.19/csu/../csu/libc-start.c:287

  #5 0x3fffa9574ef4 in __libc_start_main

/build/buildd/eglibc-2.19/csu/../sysdeps/unix/sysv/linux/powerpc/libc-start.c:93

Here, it looks like frame #0 is the one we got from GetCurrentPc(),
and frames 1 and 2 (inlined) correspond to the return address of the
frame of operator new() (at the point of GET_STACK_TRACE_MALLOC). I'm
not sure why it is, again, operator new(). Also, if there is a real
extra stack frame there, this is not guaranteed to succeed, because we
build ASan runtime library without -fno-omit-frame-pointer.

I wonder if there is a problem with __builtin_frame_address on
PowerPC, or if ALWAYS_INLINE on GetStackTraceWithPcBpAndContext did
not have any effect, or something like that?


http://reviews.llvm.org/D9259

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






More information about the llvm-commits mailing list