[compiler-rt] r220582 - Add runtime flag 'symbolize_inline_frames' to disable symbolization of inlined frames done in llvm-symbolizer

[Alexey Samsonov]

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
 section correctly. I will work on a fix for that (though, I'd probably
need help from you later with generating the test case).

Thanks!

On Wed, Oct 29, 2014 at 8:00 AM, Will Schmidt <will_schmidt at vnet.ibm.com>
wrote:

> On Tue, 2014-10-28 at 16:14 -0700, Alexey Samsonov wrote:
> > That is, the patch is not necessary?
>
> correct.
>
> > I will take a look at why we produce different function names on
> > Linux-x86 and PowerPC. Looks like we should print
> >
> > the function name corresponding to file/line location specified (that
> > is, prefer FooBarBaz). Just in case -
> > could you share a PowerPC binary for print-stack-trace.cc.tmp (with
> > inlined function) with me, so that I can debug llvm-symbolizer on it
> > if necessary?
>
> Yup, I'll send offline / separately.
>
> Thanks :-)
>
>
> > Thanks!
> >
> > On Tue, Oct 28, 2014 at 3:18 PM, Will Schmidt
> > <will_schmidt at vnet.ibm.com> wrote:
> >         On Mon, 2014-10-27 at 15:48 -0700, Alexey Samsonov wrote:
> >         > Hi Will,
> >         >
> >         >
> >         > It's possible that FooBarBaz() just doesn't get inlined.
> >         Could you
> >         > check if the attached patch fixes the test for you?
> >
> >         Thanks for the patch.  I verified that the function is being
> >         inlined
> >         with -O3 or with the inline attribute, as was expected.  I was
> >         poking a
> >         few more parts with gdb to make sense of things, and
> >         determined that I
> >         did have a stale/old object somewhere in my build..  (gdb
> >         could not find
> >         the symbolize_inline_frames field, which was obviously a bad
> >         thing.. ).
> >
> >         So with a fresh(er) build, the test still fails, but
> >         differently.  As
> >         seen below, the symbolize_inline_frames=false is causing the
> >         main()
> >         entry to be suppressed, rather than the FooBarBaz() entry.
> >
> >
> >         > export ASAN_OPTIONS=symbolize_inline_frames=true
> >         > <...>/asan/Output/print-stack-trace.cc.tmp
> >             #0 0x100c4e5c in __sanitizer_print_stack_trace
> >         <...>/asan/asan_stack.cc:23
> >             #1 0x100e2c48 in FooBarBaz
> >         <...>/TestCases/print-stack-trace.cc:12:3
> >             #2 0x100e2c48 in main
> >         <...>/TestCases/print-stack-trace.cc:16
> >             #3 0x100000424548 (/lib64/power8/libc.so.6+0x44548)
> >
> >         > export ASAN_OPTIONS=symbolize_inline_frames=false
> >         > <...>/asan/Output/print-stack-trace.cc.tmp
> >             #0 0x100c4e5c in __sanitizer_print_stack_trace
> >         <...>/asan/asan_stack.cc:23
> >             #1 0x100e2c48 in FooBarBaz
> >         <...>/TestCases/print-stack-trace.cc:12:3
> >             #2 0x100000424548 (/lib64/power8/libc.so.6+0x44548)
> >
> >         Under gdb, backtrace is:
> >         (gdb) bt
> >         #0  __sanitizer_print_stack_trace () at
> >         <...>/lib/asan/asan_stack.cc:24
> >         #1  0x00000000100e2c4c in FooBarBaz () at
> >         <...>/sanitizer_common/TestCases/print-stack-trace.cc:12
> >         #2  main () at
> >         <...>/sanitizer_common/TestCases/print-stack-trace.cc:16
> >
> >
>
>
>
>


-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141029/2fcaeb16/attachment.html>