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

Will Schmidt will_schmidt at vnet.ibm.com
Wed Oct 29 13:54:29 PDT 2014


On Wed, 2014-10-29 at 12:05 -0700, Alexey Samsonov wrote:
> 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).

Sounds good, thanks :-)

(Adding my namesake to CC for his awareness)

Note that with the (new-ish) ppc64LE support, which uses the ELFv2 ABI,
there is no .opd section, no function descriptors.  

I verified a moment ago, with a fresh build on ppc64le, that the
print-stack-trace.cc test does behave as intended, and passes there.

So the special case that you are working on should be wrapped in some
flavor of 
#if (_CALL_ELF==1)
to be limited to the Big Endian/ABIv1 PPC64 systems.

thanks, 
-Will



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





More information about the llvm-commits mailing list