<div dir="ltr">Right, I see the problem. PPC64 symbol table references function descriptors in .opd section, instead of the actual functions. So, when llvm-symbolizer overrides function names from symbol table (if --use-symbol-table=true, which is the default), it should special-case on PowerPC and handle .opd<div> section correctly. I will work on a fix for that (though, I'd probably need help from you later with generating the test case).</div><div><br></div><div>Thanks!</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 29, 2014 at 8:00 AM, Will Schmidt <span dir="ltr"><<a href="mailto:will_schmidt@vnet.ibm.com" target="_blank">will_schmidt@vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, 2014-10-28 at 16:14 -0700, Alexey Samsonov wrote:<br>
> That is, the patch is not necessary?<br>
<br>
</span>correct.<br>
<span class=""><br>
> I will take a look at why we produce different function names on<br>
> Linux-x86 and PowerPC. Looks like we should print<br>
><br>
> the function name corresponding to file/line location specified (that<br>
> is, prefer FooBarBaz). Just in case -<br>
> could you share a PowerPC binary for print-stack-trace.cc.tmp (with<br>
> inlined function) with me, so that I can debug llvm-symbolizer on it<br>
> if necessary?<br>
<br>
</span>Yup, I'll send offline / separately.<br>
<br>
Thanks :-)<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> Thanks!<br>
><br>
> On Tue, Oct 28, 2014 at 3:18 PM, Will Schmidt<br>
> <<a href="mailto:will_schmidt@vnet.ibm.com">will_schmidt@vnet.ibm.com</a>> wrote:<br>
> On Mon, 2014-10-27 at 15:48 -0700, Alexey Samsonov wrote:<br>
> > Hi Will,<br>
> ><br>
> ><br>
> > It's possible that FooBarBaz() just doesn't get inlined.<br>
> Could you<br>
> > check if the attached patch fixes the test for you?<br>
><br>
> Thanks for the patch. I verified that the function is being<br>
> inlined<br>
> with -O3 or with the inline attribute, as was expected. I was<br>
> poking a<br>
> few more parts with gdb to make sense of things, and<br>
> determined that I<br>
> did have a stale/old object somewhere in my build.. (gdb<br>
> could not find<br>
> the symbolize_inline_frames field, which was obviously a bad<br>
> thing.. ).<br>
><br>
> So with a fresh(er) build, the test still fails, but<br>
> differently. As<br>
> seen below, the symbolize_inline_frames=false is causing the<br>
> main()<br>
> entry to be suppressed, rather than the FooBarBaz() entry.<br>
><br>
><br>
> > export ASAN_OPTIONS=symbolize_inline_frames=true<br>
> > <...>/asan/Output/print-stack-trace.cc.tmp<br>
> #0 0x100c4e5c in __sanitizer_print_stack_trace<br>
> <...>/asan/asan_stack.cc:23<br>
> #1 0x100e2c48 in FooBarBaz<br>
> <...>/TestCases/print-stack-trace.cc:12:3<br>
> #2 0x100e2c48 in main<br>
> <...>/TestCases/print-stack-trace.cc:16<br>
> #3 0x100000424548 (/lib64/power8/libc.so.6+0x44548)<br>
><br>
> > export ASAN_OPTIONS=symbolize_inline_frames=false<br>
> > <...>/asan/Output/print-stack-trace.cc.tmp<br>
> #0 0x100c4e5c in __sanitizer_print_stack_trace<br>
> <...>/asan/asan_stack.cc:23<br>
> #1 0x100e2c48 in FooBarBaz<br>
> <...>/TestCases/print-stack-trace.cc:12:3<br>
> #2 0x100000424548 (/lib64/power8/libc.so.6+0x44548)<br>
><br>
> Under gdb, backtrace is:<br>
> (gdb) bt<br>
> #0 __sanitizer_print_stack_trace () at<br>
> <...>/lib/asan/asan_stack.cc:24<br>
> #1 0x00000000100e2c4c in FooBarBaz () at<br>
> <...>/sanitizer_common/TestCases/print-stack-trace.cc:12<br>
> #2 main () at<br>
> <...>/sanitizer_common/TestCases/print-stack-trace.cc:16<br>
><br>
><br>
<br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div>
</div>