Hi Tom!
On Mon, 25 Feb 2019 18:11:23 +0100, Tom de Vries <[email protected]> wrote:
> On 25-02-19 11:48, Thomas Schwinge wrote:
> > On Fri, 8 Feb 2019 10:42:24 +0100, Tom de Vries <[email protected]> wrote:
> >> Add libbacktrace test-case using -flto.
> >
> > I'm seeing this one fail is some configurations, but only in the
> > 'build-gcc/libbacktrace/btest_lto.log' variant:
> Meaning, compiling libbacktrace using the host compiler, so it would be
> useful to known which compiler that is.
>
> [ I've tried a gcc-4.8 and gcc-6 and gcc-7 as host compiler, and a
> couple of CFLAGS settings (-O2, -O3) to reproduce this, but didn't manage. ]
Years old:
$ gcc --version
gcc (Sourcery CodeBench 2014.05-45) 4.8.3 20140320 (prerelease)
[...]
$ ld --version
GNU ld (Sourcery CodeBench 2014.05-45) 2.24.51.20140217
[...]
(It'll be fine for me if you just declare that unsupported.)
> > test5: unexpected syminfo name got global.2537 expected global
> > PASS: backtrace_full noinline
> > PASS: backtrace_full inline
> > PASS: backtrace_simple noinline
> > PASS: backtrace_simple inline
> > FAIL: backtrace_syminfo variable
> > FAIL btest_lto (exit status: 1)
> >
> > I haven't looked yet which details about these GCC build configurations
> > might be different/important; maybe you've got an idea already?
I can reproduce this with '-O0' ("unexpected syminfo name got global.2528
expected global", in that case). With '-O0 -fdump-tree-all
-fdump-ipa-all -save-temps', the 'global.2528' name appears only in
'btest_lto.ltrans0.000i.cgraph', and 'btest_lto.ltrans0.s':
./btest_lto.ltrans0.000i.cgraph: References: global.2528/12
(addr)state.2526/56 (read)callback_three.2389/64
(addr)error_callback_three.2384/65 (addr)stderr/20 (read)stderr/20
(read)stderr/20 (read)global.2528/12 (addr)global.2528/12 (addr)stderr/20
(read)stderr/20 (read)failures.2527/57 (read)failures.2527/57
(write)failures.2527/57 (read)
./btest_lto.ltrans0.000i.cgraph:global.2528/12 (global) @0xf7454118
./btest_lto.ltrans0.000i.cgraph:global.2528/12 (global) @0xf7454118
./btest_lto.ltrans0.000i.cgraph: References: global.2528/12
(addr)state.2526/56 (read)callback_three.2389/64
(addr)error_callback_three.2384/65 (addr)stderr/20 (read)stderr/20
(read)stderr/20 (read)global.2528/12 (addr)global.2528/12 (addr)stderr/20
(read)stderr/20 (read)failures.2527/57 (read)failures.2527/57
(write)failures.2527/57 (read)
./btest_lto.ltrans0.000i.cgraph:global.2528/12 (global) @0xf7454118
./btest_lto.ltrans0.000i.cgraph: References: global.2528/12
(addr)state.2526/56 (read)callback_three.2389/64
(addr)error_callback_three.2384/65 (addr)stderr/20 (read)stderr/20
(read)stderr/20 (read)global.2528/12 (addr)global.2528/12 (addr)stderr/20
(read)stderr/20 (read)failures.2527/57 (read)failures.2527/57
(write)failures.2527/57 (read)
./btest_lto.ltrans0.s: .type global.2528, @object
./btest_lto.ltrans0.s: .size global.2528, 4
./btest_lto.ltrans0.s:global.2528:
./btest_lto.ltrans0.s: movq $global.2528, -8(%rbp) #, addr
./btest_lto.ltrans0.s: movl $global.2528, %eax #, global.22
./btest_lto.ltrans0.s: movl $global.2528, %ecx #, global.23
./btest_lto.ltrans0.s: .quad global.2528
> Well, the backtrace_syminfo function looks at the minimal symbol info
> (so, not the dwarf info) and it seems lto has done an optimization that
> has changed the name of the variable in the minimal symbol info.
>
> There's probably a standard way to annotate the 'global' variable to
> prevent the optimization from happening, which would fix the failure
> (but, we need to know which optimization renamed it).
>
> OTOH, we could just limit this test to target libbacktrace only, given
> the fact that host compilers may not even support flto.
Grüße
Thomas
