[Bug gold/12629] New: lto, linker-plugin and optimization clutter the stack trace when using gold

[vincenzo.innocente at cern dot ch]

http://sourceware.org/bugzilla/show_bug.cgi?id=12629

           Summary: lto, linker-plugin and optimization clutter the stack
                    trace when using gold
           Product: binutils
           Version: 2.21
            Status: NEW
          Severity: critical
          Priority: P2
         Component: gold
        AssignedTo: address@hidden
        ReportedBy: address@hidden


Created attachment 5348
  --> http://sourceware.org/bugzilla/attachment.cgi?id=5348
an header file, three compilation units, a script to source that will produce
several shared libraries and executable

I submitted this bug report to gcc first
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48384
It actually turned out to be a regression of gold w.r.t. standard bfd  "ld".
I'm not yet sure if the problem is on the binutil or gcc side.
Below is a copy of my original post to gcc- bugzilla
Please refer to gcc bug report for the more details.

-----------------------------------------------------

I'm testing lto and the linker-plugin within shared libraries.
Results using hidden visibility are very encouraging. Unfortunately the
combination of even mild optimization (O2) and -flto -fuse-linker-plugin seems
to clutter the stack-trace. This can be easily
shown in gdb. It makes also instrumentation tools, that rely on stack trace, to
either crash or produce wrong results.

I'm using 
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-gold=yes --enable-lto --with-fpmath=avx
Thread model: posix
gcc version 4.6.1 20110325 (prerelease) (GCC) 

GNU gold (GNU Binutils 2.21) 1.10

Linux vinavx0.cern.ch 2.6.32-71.14.1.el6.x86_64 #1 SMP Thu Jan 13 12:03:40 CET
2011 x86_64 x86_64 x86_64 GNU/Linux

glibc.x86_64                           2.12-1.7.el6_0.4  
GNU gdb (GDB) Red Hat Enterprise Linux (7.1-29.el6_0.1)


In  the attachment there are the four  files of my simple test (a long loop and
a seg-fault)
and a script that builds various versions
just compare
g++ -g -DHIDDEN go.cc foo.cc -flto -fuse-linker-plugin -fPIC -shared -o
libfoo_hltog.so
g++ -g -DHIDDEN main.cc -flto -fuse-linker-plugin -L./ -lfoo_hltog -o t_hltog
with
g++ -O2 -g -DHIDDEN go.cc foo.cc -flto -fuse-linker-plugin -fPIC -shared -o
libfoo_hltog2.so
g++ -O2 -g -DHIDDEN main.cc -flto -fuse-linker-plugin -L./ -lfoo_hltog2 -o
t_hltog2

the first looks ok,
(the segmentation fault deferencing a zero pointer is intentional)
the latter in gdb will produce
(gdb) run
Starting program: /afs/cern.ch/user/i/innocent/public/ctest/lto/t_hltog2 
Program received signal SIGSEGV, Segmentation fault.
go (j=Cannot access memory at address 0x0
) at go.cc:5
5      j+= foo(h);
Missing separate debuginfos, use: debuginfo-install
glibc-2.12-1.7.el6_0.4.x86_64
(gdb) where
#0  go (j=Cannot access memory at address 0x0
) at go.cc:5
#1  0x00000000000003e8 in ?? ()
#2  0x42c800004232ee1f in ?? ()
#3  0x0000000000000000 in ?? ()
(gdb) run 2
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /afs/cern.ch/user/i/innocent/public/ctest/lto/t_hltog2 2
^C
Program received signal SIGINT, Interrupt.
0x0000003ff6207ebd in __ieee754_asin () from /lib64/libm.so.6
(gdb) where
#0  0x0000003ff6207ebd in __ieee754_asin () from /lib64/libm.so.6
#1  0x0000003ff6224842 in asin () from /lib64/libm.so.6
#2  0x00007ffff7ffb6aa in bar (j=20000001, h=0x0) at foo.cc:14
#3  go (j=20000001, h=0x0) at go.cc:4
#4  0x0000000000989680 in ?? ()
#5  0x3f8000003f800001 in ?? ()
#6  0x0000000000000000 in ?? ()
(gdb) 


in more complex applications with multiple shared libraries things gets much
more confused with "??"
all over the srack-trace

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.