Re: binutils 2.9.5.0.5 still trigger the last bug - static libstdc++ required

[hjl at lucon dot org (H.J. Lu)]

> 
> Jakub Jelinek writes:
>  > >     after Ian checked in your patch yesterday morning I still had this
>  > > problem - with binutils-2.9.5.0.5 I can no longer reproduce it though.
>  > > 
>  > >     Should I try it again with an updated cvs version?
>  > 
>  > Strange. 2.9.5.0.5 seems to have my patch and from that time on I'm not
>  > aware of any sparc related changes.
>  > If you can, could you check latest cvs version? If the problem remains,
>  > could you please send me the binary of libNope.so from old binutils, cvs
>  > mainline and perhaps 2.9.5.0.5?
>  > I could arrange to get access to one Solaris box, but it would take a few
>  > days, so it would be easier for me to inspect things on a sparc64-linux box.
> 
> Jakub, Ian, H.J,
> 
>    here we go - the bug is still present in both binutils-2.9.5.0.5
> and the current cvs tree.
> 
>    You can however only trigger it by linking against a static 
> libstd++ (the only way I could convince gcc to avoid the .so was
> to chmod 0 libstdc++.so*). The bug does not show up when you link
> against a dynamic libstd++.
> 
>    So after you run chmod 0 on your libstd++.so* (or build gcc without
> --enable-shared) you should run the script below to see the core dump
> and the behaviour described below.

The bug has been in binutils for a while. Ian, Jakub, with "make check"
in ld, I got

FAIL: shared (non PIC)
FAIL: shared (non PIC, load offset)
FAIL: shared (PIC main, non PIC so)

I believe it is related to this bug. When

# g++ -G -o libNope.so libNope.C

is used to generate a DSO, -lstdc++ is passed to ld. If there is no
libstd++.so, libstdc++.a will be used. However, gnu ld doesn't do the
right thing on Solaris/Sparc. Before gnu ld is fixed, the workarounds
are:

1. Use the native ld. Or
2. Use 

# gcc -G -o libNope.so libNope.C

instead of

# g++ -G -o libNope.so libNope.C

It is better than putting non PIC code in a shared library. Or
3. Fix g++ such that passing -lstdc++ to ld for -G/-shared when
building shared library only if --enable-shared is used. It doesn't
make any senses to include libstdc++.a for a DSO.

My preferences are 3, 2 and 1. I may work on a patch for 3 if everyone
thinks it is a good idea.

Thanks.


H.J.
----
> 
>    Hope this helps.
> 
> 
>       You guys are great - but you know that ;-)
> 
>                   Wolfgang
> 
> To: Ian Lance Taylor <ian@zembu.com>
> Cc: hjl@lucon.org
> Subject: Re: binutils 2.9.1.0.25 - solaris / gcc2.95
> Date: Fri, 6 Aug 1999 13:19:57 -0400 (EDT)
> 
> Ian and H.J.,
> 
>   here is another problem I ran into - it seems not to be gcc related
> as static linking does not trigger the bug.
> 
> The following example code
> 
> ----------------------------------------------------------------------
> #!/bin/sh
> 
> echo '
> void bugme(void);
> int main() {
>     bugme();
> }' > test.C
> 
> echo '
> #include <iostream>
> #include <strstream>
> #include <string>
> void bugme(void) {
>   string a_string("a string of some size");
>   ostrstream ostr;
>   ostr << a_string << '"'"'\0'"'"';
>   cout << ostr.str() << endl;
>   ostr.freeze(false);
> }
> ' > libNope.C
> 
> 
> CC="g++-2.95-gnu -fPIC -g"
> $CC -G -o libNope.so libNope.C
> $CC -c -o libNope.o libNope.C
> ar rv libNope.a libNope.o
> $CC -g test.C -o bug -L. -lNope -Wl,-R`pwd`
> $CC -g -static test.C -o nobug -L. -lNope
> 
> echo '==============='
> echo 'output of bug'
> ./bug
> echo 'output of nobug'
> ./nobug
> 
> 
> ----------------------------------------------------------------------
> produces (on solaris 2.6 with the binutils checked out this morning):
> 
> -----------------
> output of bug
> Segmentation Fault - core dumped
> output of nobug
> a string of some size
> ------------------
> 
> so the dynamicly linked executable crashes whereas the static one is
> fine.
> 
> It crashes in _IO_str_overflow where
> 
> 143               new_buf
> 144                 = (char *) (*((_IO_strfile *)
> fp)->_s._allocate_buffer) (new_size);
> 
> 
> 
> ((_IO_strfile *) fp)->_s is a *static* member of ostrstream and its
> data member point to point to undefined addresses - looks like another
> static constructor problem (if I may guess so ;-)
> 
> 
> (gdb) print ((_IO_strfile *) fp)->_s
> $3 = {_allocate_buffer = 0xef747848 <errno_funcp+138348>, _free_buffer
> = 0xef747
> 85c <errno_funcp+138368>}
> 
> 
> If I link the binary dynamicly I get (at the same breakpoint)
> 
> 
> (gdb) print ((_IO_strfile *) fp)->_s
> $1 = {_allocate_buffer = 0x178f8 <default_alloc(unsigned int)>,
> _free_buffer = 0
> x1790c <default_free(void *)>}
> 
> 
> egcs-1.1.2 (binutils 2.9.1) works for both the dynamic and the static
> case.
> 
> 
>                    Wolfgang
> 
>