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

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

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

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

[Ian Lance Taylor]

   Date: Sat, 7 Aug 1999 16:21:12 -0700 (PDT)
   From: hjl@lucon.org (H.J. Lu)

I don't have an easy way to test problems on Solaris, so I'm waiting
for somebody to find the problem or produce a test case I can look at
(i.e., one which does not require building gcc or libstdc++ and which
does not require the Solaris startup files or libraries).

   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)

This suggests a bug in handling relocations when generating shared
libraries.

   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.

To me it makes perfect sense to include libstdc++.a in a shared
object.  Anyhow, it seems silly to patch g++ merely because there is a
bug in ld.  We should just fix the bug in ld.  A bug like this can't
be hard to fix, especially since the GNU linker used to pass those
tests on Solaris.

Ian

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

[H.J. Lu]

> 
>    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)
> 
> This suggests a bug in handling relocations when generating shared
> libraries.
> 
> To me it makes perfect sense to include libstdc++.a in a shared
> object.  Anyhow, it seems silly to patch g++ merely because there is a
> bug in ld.  We should just fix the bug in ld.  A bug like this can't
> be hard to fix, especially since the GNU linker used to pass those
> tests on Solaris.
> 

binutils 2.9.1.0.25, which is basically binutils 2.9.1, failed those
tests. I am no expert on Sparc. I don't know how it got broken. I
will give it a try when I find time.


-- 
H.J. Lu (hjl@gnu.org)

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

[Ian Lance Taylor]

   Date: Sat, 7 Aug 1999 18:17:42 -0700 (PDT)
   From: hjl@lucon.org (H.J. Lu)

   >    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)
   > 
   > This suggests a bug in handling relocations when generating shared
   > libraries.
   > 
   > To me it makes perfect sense to include libstdc++.a in a shared
   > object.  Anyhow, it seems silly to patch g++ merely because there is a
   > bug in ld.  We should just fix the bug in ld.  A bug like this can't
   > be hard to fix, especially since the GNU linker used to pass those
   > tests on Solaris.

   binutils 2.9.1.0.25, which is basically binutils 2.9.1, failed those
   tests. I am no expert on Sparc. I don't know how it got broken. I
   will give it a try when I find time.

When I used to run tests on Solaris those tests passed (well, the load
offset test did not exist at that time, and I'm not concerned if it
doesn't pass).

Ian

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

[H.J. Lu]

> 
>    Date: Sat, 7 Aug 1999 18:17:42 -0700 (PDT)
>    From: hjl@lucon.org (H.J. Lu)
> 
>    >    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)
>    > 
>    > This suggests a bug in handling relocations when generating shared
>    > libraries.
>    > 
>    > To me it makes perfect sense to include libstdc++.a in a shared
>    > object.  Anyhow, it seems silly to patch g++ merely because there is a
>    > bug in ld.  We should just fix the bug in ld.  A bug like this can't
>    > be hard to fix, especially since the GNU linker used to pass those
>    > tests on Solaris.
> 
>    binutils 2.9.1.0.25, which is basically binutils 2.9.1, failed those
>    tests. I am no expert on Sparc. I don't know how it got broken. I
>    will give it a try when I find time.
> 
> When I used to run tests on Solaris those tests passed (well, the load
> offset test did not exist at that time, and I'm not concerned if it
> doesn't pass).
> 
> Ian
> 

This patch from David breaks none-PIC in DSO. David, can you tell
us why this patch is needed and could you please run "make check"
in ld on binutils 2.9.l.0.25 on Linux/Sparc?

Thanks.


-- 
H.J. Lu (hjl@gnu.org)
---
Fri Sep  4 13:54:23 1998  David Miller  <davem@dm.cobaltmicro.com>

	* elf32-sparc.c (elf32_sparc_relocate_section): Properly adjust 
	the addend of a dynamic relocation referencing a section.
	* elf64-sparc.c (sparc64_elf_relocate_section): Likewise.
	(sparc64_elf_finish_dynamic_symbol): Fix the PLT relocation 
	offset.

diff -upr binutils-2.9.1.0.22/bfd/elf64-sparc.c binutils-2.9.1.0.23/bfd/elf64-sparc.c
--- binutils-2.9.1.0.22/bfd/elf64-sparc.c	Fri Dec  4 19:38:53 1998
+++ binutils-2.9.1.0.23/bfd/elf64-sparc.c	Wed Mar 31 09:24:48 1999
@@ -1590,7 +1590,15 @@ sparc64_elf_relocate_section (output_bfd
 			  }
 
 			outrel.r_info = ELF64_R_INFO (indx, r_type);
-			outrel.r_addend = relocation + rel->r_addend;
+
+			/* For non-RELATIVE dynamic relocations, we keep the
+			   same symbol, and so generally the same addend.  But
+			   we do need to adjust those relocations referencing
+			   sections.  */
+			outrel.r_addend = rel->r_addend;
+			if (r_symndx < symtab_hdr->sh_info
+			    && ELF_ST_TYPE (sym->st_info) == STT_SECTION)
+			  outrel.r_addend += sec->output_offset + sym->st_value;
 		      }
 		  }
 
@@ -1904,6 +1912,7 @@ sparc64_elf_finish_dynamic_symbol (outpu
 	  rela.r_offset = sparc64_elf_plt_ptr_offset (h->plt_offset, max);
 	  rela.r_addend = -(sparc64_elf_plt_entry_offset (h->plt_offset) + 4);
 	}
+      rela.r_offset += (splt->output_section->vma + splt->output_offset);
       rela.r_info = ELF64_R_INFO (h->dynindx, R_SPARC_JMP_SLOT);
 
       bfd_elf64_swap_reloca_out (output_bfd, &rela,

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

[Ian Lance Taylor]

   Date: Sat, 7 Aug 1999 23:02:31 -0700 (PDT)
   From: hjl@lucon.org (H.J. Lu)

   This patch from David breaks none-PIC in DSO. David, can you tell
   us why this patch is needed and could you please run "make check"
   in ld on binutils 2.9.l.0.25 on Linux/Sparc?

H.J., thanks for tracking down the problem.

David's patch to elf32-sparc.c is wrong.  It presumes that we keep the
same symbol for a dynamic relocation.  However, in the case in
question, we do not.

David's patch applies to a piece of code which is only executed if
there is no global symbol, or if we are not supposed to generate a
relocation against the global symbol.  The code converts the
relocation to be against a section symbol.

So this comment is incorrect:

      /* For non-RELATIVE dynamic relocations, we keep the
	 same symbol, and so generally the same addend.  But
	 we do need to adjust those relocations referencing
	 sections.  */

We do not keep the same symbol.  Moreover, the actual code tests SYM
to see whether it is a section symbol, but at that point SYM is
irrelevant.  At that point we will always use a section symbol.

My inclination is to simply revert the patch.  However, I gather from
Jakub's message that that will break something on SPARC/GNU/Linux.
What will it break?

Ian

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

[H.J. Lu]

> 
>    Date: Sat, 7 Aug 1999 23:02:31 -0700 (PDT)
>    From: hjl@lucon.org (H.J. Lu)
> 
>    This patch from David breaks none-PIC in DSO. David, can you tell
>    us why this patch is needed and could you please run "make check"
>    in ld on binutils 2.9.l.0.25 on Linux/Sparc?
> 
> H.J., thanks for tracking down the problem.
> 
> David's patch to elf32-sparc.c is wrong.  It presumes that we keep the
> same symbol for a dynamic relocation.  However, in the case in
> question, we do not.
> 
> David's patch applies to a piece of code which is only executed if
> there is no global symbol, or if we are not supposed to generate a
> relocation against the global symbol.  The code converts the
> relocation to be against a section symbol.
> 
> So this comment is incorrect:
> 
>       /* For non-RELATIVE dynamic relocations, we keep the
> 	 same symbol, and so generally the same addend.  But
> 	 we do need to adjust those relocations referencing
> 	 sections.  */
> 
> We do not keep the same symbol.  Moreover, the actual code tests SYM
> to see whether it is a section symbol, but at that point SYM is
> irrelevant.  At that point we will always use a section symbol.
> 
> My inclination is to simply revert the patch.  However, I gather from
> Jakub's message that that will break something on SPARC/GNU/Linux.
> What will it break?
> 

If it is true, I tend to believe it is a dynamic linker bug in glibc
since there is no problem with Solaris. I suggest we revert the patch
in bfd and deal with it in the glibc dynamic linker.


-- 
H.J. Lu (hjl@gnu.org)

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

[Ian Lance Taylor]

   Date: Sun, 8 Aug 1999 09:08:13 -0700 (PDT)
   From: hjl@lucon.org (H.J. Lu)

   > My inclination is to simply revert the patch.  However, I gather from
   > Jakub's message that that will break something on SPARC/GNU/Linux.
   > What will it break?

   If it is true, I tend to believe it is a dynamic linker bug in glibc
   since there is no problem with Solaris. I suggest we revert the patch
   in bfd and deal with it in the glibc dynamic linker.

As always, I think that before we take any action, we should figure
out what the actual problem is.  What's the rush?

It's possible that the original linker code is buggy in a manner which
arises on GNU/Linux but not on Solaris.  Certainly something needs to
be changed, but since we don't yet know what the problem is (at least
I don't) we don't yet know for sure whether we have to change the
binutils or glibc.

Ian

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

[Jakub Jelinek]

> 
> This patch from David breaks none-PIC in DSO. David, can you tell
> us why this patch is needed and could you please run "make check"
> in ld on binutils 2.9.l.0.25 on Linux/Sparc?

Ok, I believe it was because of the glibc 2.0.x dynamic linker bug, because
glibc 2.1.1 and glibc 2.1.90 require that change to be back out (well, the
finish_dynamic_symbol should stay), otherwise things dump core.
glibc 2.1.x+ dl-machine.h (example for sparc32) looks like:

      const Elf32_Sym *const refsym = sym;
      Elf32_Addr value;
      if (sym->st_shndx != SHN_UNDEF &&
          ELF32_ST_BIND (sym->st_info) == STB_LOCAL)
        value = map->l_addr;
      else
        {
          value = RESOLVE (&sym, version, ELF32_R_TYPE (reloc->r_info));
          if (sym)
            value += sym->st_value;
        }
      value += reloc->r_addend; /* Assume copy relocs have zero addend.  */
      ...

while glibc 2.0.x reads as:

      const int r_type = ELF32_R_TYPE (reloc->r_info);
      Elf32_Addr value;

      value = RESOLVE (&sym, (r_type == R_SPARC_COPY ? DL_LOOKUP_NOEXEC
                             : r_type == R_SPARC_JMP_SLOT ? DL_LOOKUP_NOPLT
                             : 0));
      if (sym)
        value += sym->st_value;
      value += reloc->r_addend;        /* Assume copy relocs have zero addend.  */
      ...

In fact, glibc 2.0.x had sparc-linux support even more broken, RedHat
shipped ~450k of SPARC patches for it and the dl-machine.h buggy code was in
the patch.

1999-08-09  Jakub Jelinek  <jj@ultra.linux.cz>

	* elf64-sparc.c (sparc64_elf_relocate_section): Back out part of the
	Sep, 4th, 1998 change. glibc 2.0.x dynamic linker had bug, not
	binutils.
	* elf32-sparc.c (elf32_sparc_relocate_section): Likewise.

--- elf32-sparc.c.jj	Fri Jul 23 15:31:15 1999
+++ elf32-sparc.c	Mon Aug  9 10:05:49 1999
@@ -1475,15 +1475,7 @@ elf32_sparc_relocate_section (output_bfd
 			}
 
 		      outrel.r_info = ELF32_R_INFO (indx, r_type);
-
-		      /* For non-RELATIVE dynamic relocations, we keep the
-			 same symbol, and so generally the same addend.  But
-			 we do need to adjust those relocations referencing
-			 sections.  */
-		      outrel.r_addend = rel->r_addend;
-		      if (r_symndx < symtab_hdr->sh_info
-			  && ELF_ST_TYPE (sym->st_info) == STT_SECTION)
-		        outrel.r_addend += sec->output_offset+sym->st_value;
+		      outrel.r_addend = relocation + rel->r_addend;
 		    }
 		}
 
--- elf64-sparc.c	Mon Aug  2 09:39:54 1999
+++ elf64-sparc.c	Mon Aug  9 10:06:16 1999
@@ -2249,15 +2249,7 @@ sparc64_elf_relocate_section (output_bfd
 					  ELF64_R_TYPE_INFO (
 					    ELF64_R_TYPE_DATA (rel->r_info),
 							       r_type));
-
-			/* For non-RELATIVE dynamic relocations, we keep the
-			   same symbol, and so generally the same addend.  But
-			   we do need to adjust those relocations referencing
-			   sections.  */
-			outrel.r_addend = rel->r_addend;
-			if (r_symndx < symtab_hdr->sh_info
-			    && ELF_ST_TYPE (sym->st_info) == STT_SECTION)
-			  outrel.r_addend += sec->output_offset+sym->st_value;
+			outrel.r_addend = relocation + rel->r_addend;
 		      }
 		  }
 


Cheers,
    Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
UltraLinux  |  http://ultra.linux.cz/  |  http://ultra.penguin.cz/
Linux version 2.3.13 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________

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

[Ian Lance Taylor]

   Date: Mon, 9 Aug 1999 10:53:03 +0200
   From: Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz>

   Ok, I believe it was because of the glibc 2.0.x dynamic linker bug, because
   glibc 2.1.1 and glibc 2.1.90 require that change to be back out (well, the
   finish_dynamic_symbol should stay), otherwise things dump core.

   1999-08-09  Jakub Jelinek  <jj@ultra.linux.cz>

	   * elf64-sparc.c (sparc64_elf_relocate_section): Back out part of the
	   Sep, 4th, 1998 change. glibc 2.0.x dynamic linker had bug, not
	   binutils.
	   * elf32-sparc.c (elf32_sparc_relocate_section): Likewise.

Thanks for looking into this.  I checked in this patch.

Wolfgang, please let us know if there are any remaining problems on
Solaris.

Ian

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

[Wolfgang Wander]

Ian Lance Taylor writes:
 >    Date: Mon, 9 Aug 1999 10:53:03 +0200
 >    From: Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz>
 > 
 >    Ok, I believe it was because of the glibc 2.0.x dynamic linker bug, because
 >    glibc 2.1.1 and glibc 2.1.90 require that change to be back out (well, the
 >    finish_dynamic_symbol should stay), otherwise things dump core.
 > 
 >    1999-08-09  Jakub Jelinek  <jj@ultra.linux.cz>
 > 
 > 	   * elf64-sparc.c (sparc64_elf_relocate_section): Back out part of the
 > 	   Sep, 4th, 1998 change. glibc 2.0.x dynamic linker had bug, not
 > 	   binutils.
 > 	   * elf32-sparc.c (elf32_sparc_relocate_section): Likewise.
 > 
 > Thanks for looking into this.  I checked in this patch.
 > 
 > Wolfgang, please let us know if there are any remaining problems on
 > Solaris.

Great - this does solve the problem with the static libstdc++ and
a dynamic user library.

Not that I understand why the glibc dynamic linker refers to our
solaris problem but I guess I don't have to. 

           Thanks!

                     Wolfgang