[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