Re: The Linux binutils 2.11.92.0.7 is released.

Re: The Linux binutils 2.11.92.0.7 is released.

[H . J . Lu]

On Tue, Oct 16, 2001 at 09:34:44PM -0700, Josue Amaro wrote:
> H. J.,
> 
> I need some information about the implementation of "-z defs" on ld.  
> Does it behave the same way that the Solaris tools do?
> Since -z options were included for Solaris compatibility, shouldn't it 
> behave in the same way?

It is supposed to behave the same. But I don't know what Solaris' ld
does when symbols are missing from DSOs being linked against.

> Should -z defs ignore the glibc missing symbols?

The -z defs option in the GNU ld ignores symbols missing from DSOs
being linked against. It is done on purpose. The theory is if you want
to make sure those DSOs are ok, you should build them with -z defs. If
you don't build them, you have to assume they are ok.


H.J.

Re: The Linux binutils 2.11.92.0.7 is released.

[Jakub Jelinek]

On Tue, Oct 16, 2001 at 11:18:42PM -0700, H . J . Lu wrote:
> On Tue, Oct 16, 2001 at 09:34:44PM -0700, Josue Amaro wrote:
> > H. J.,
> > 
> > I need some information about the implementation of "-z defs" on ld.  
> > Does it behave the same way that the Solaris tools do?
> > Since -z options were included for Solaris compatibility, shouldn't it 
> > behave in the same way?
> 
> It is supposed to behave the same. But I don't know what Solaris' ld
> does when symbols are missing from DSOs being linked against.
> 
> > Should -z defs ignore the glibc missing symbols?
> 
> The -z defs option in the GNU ld ignores symbols missing from DSOs
> being linked against. It is done on purpose. The theory is if you want
> to make sure those DSOs are ok, you should build them with -z defs. If
> you don't build them, you have to assume they are ok.

I don't know what Solaris does exactly in -z defs about the interpreter, but
at least on glibc systems it would IMHO make sense to allow satisfying
symbols for -z defs with symbols from dynamic linker as glibc relies on
this behaviour (otherwise one has to use -z defs only with explicit
/lib/ld-*.so on the command line).

	Jakub

Why deos ELF/PPC care R_PPC_NONE?

[H . J . Lu]

On Thu, Oct 18, 2001 at 05:04:22PM +0200, Franz Sirl wrote:
> At 05:13 17.10.2001, you wrote:
> >Please test it as much as you can and report all the regressions.
> 
> This one doesn't work correctly on PPC, it fails to build gcc-2.95.4:
> 
> [fsirl@entropy:~/rh70/gcc295/BUILD/obj-gcc-ppc/ppc-linux/libstdc++]$ 
> /home/fsirl/rh70/gcc295/BUILD/obj-gcc-ppc/gcc/xgcc 
> -B/home/fsirl/rh70/gcc295/BUILD/obj-gcc-ppc/gcc/ -B/usr/ppc-linux/bin/ 
> -Wl,-z,nocombreloc -g -O2 -fvtable-thunks -D_GNU_SOURCE 
> -fno-implicit-templates -Wl,-soname,libstdc++-libc6.2-2.so.3 -shared -o 
> libstdc++-3-libc6.2-2-2.10.0.so `cat piclist` -lm -v -Wl,-vReading specs 
> from /home/fsirl/rh70/gcc295/BUILD/obj-gcc-ppc/gcc/specs
> gcc version 2.95.4 20010319 (prerelease/franzo/20010912)
>   /home/fsirl/rh70/gcc295/BUILD/obj-gcc-ppc/gcc/collect2 -m elf32ppclinux 
> -shared -o libstdc++-3-libc6.2-2-2.10.0.so /usr/lib/crti.o 
> /home/fsirl/rh70/gcc295/BUILD/obj-gcc-ppc/gcc/crtbeginS.o 
> -L/home/fsirl/rh70/gcc295/BUILD/obj-gcc-ppc/gcc 
> -L/usr/lib/gcc-lib/ppc-linux/2.95.4 -z nocombreloc -soname 
> libstdc++-libc6.2-2.so.3 pic/cmathi.o pic/cstdlibi.o pic/cstringi.o 
> pic/cstrio.o pic/cstrmain.o pic/dcomio.o pic/dcomplex.o pic/fcomio.o 
> pic/fcomplex.o pic/ldcomio.o pic/ldcomplex.o pic/stdexcepti.o pic/stlinst.o 
> pic/valarray.o ../libio/pic/iogetline.o ../libio/pic/builtinbuf.o 
> ../libio/pic/filebuf.o ../libio/pic/fstream.o ../libio/pic/indstream.o 
> ../libio/pic/ioassign.o ../libio/pic/ioextend.o ../libio/pic/iomanip.o 
> ../libio/pic/iostream.o ../libio/pic/isgetline.o ../libio/pic/isgetsb.o 
> ../libio/pic/isscan.o ../libio/pic/osform.o ../libio/pic/procbuf.o 
> ../libio/pic/sbform.o ../libio/pic/sbgetline.o ../libio/pic/sbscan.o 
> ../libio/pic/stdiostream.o ../libio/pic/stdstrbufs.o 
> ../libio/pic/stdstreams.o ../libio/pic/stream.o ../libio/pic/streambuf.o 
> ../libio/pic/strstream.o ../libio/pic/PlotFile.o ../libio/pic/SFile.o 
> ../libio/pic/parsestream.o ../libio/pic/pfstream.o ../libio/pic/editbuf.o 
> ../libiberty/pic/strerror.o -lm -v -lgcc -lc -lgcc 
> /home/fsirl/rh70/gcc295/BUILD/obj-gcc-ppc/gcc/crtendS.o /usr/lib/crtn.o
> collect2 version 2.95.4 20010319 (prerelease/franzo/20010912) (PowerPC 
> GNU/Linux)
> /usr/bin/ld -m elf32ppclinux -shared -o libstdc++-3-libc6.2-2-2.10.0.so 
> /usr/lib/crti.o /home/fsirl/rh70/gcc295/BUILD/obj-gcc-ppc/gcc/crtbeginS.o 
> -L/home/fsirl/rh70/gcc295/BUILD/obj-gcc-ppc/gcc 
> -L/usr/lib/gcc-lib/ppc-linux/2.95.4 -z nocombreloc -soname 
> libstdc++-libc6.2-2.so.3 pic/cmathi.o pic/cstdlibi.o pic/cstringi.o 
> pic/cstrio.o pic/cstrmain.o pic/dcomio.o pic/dcomplex.o pic/fcomio.o 
> pic/fcomplex.o pic/ldcomio.o pic/ldcomplex.o pic/stdexcepti.o pic/stlinst.o 
> pic/valarray.o ../libio/pic/iogetline.o ../libio/pic/builtinbuf.o 
> ../libio/pic/filebuf.o ../libio/pic/fstream.o ../libio/pic/indstream.o 
> ../libio/pic/ioassign.o ../libio/pic/ioextend.o ../libio/pic/iomanip.o 
> ../libio/pic/iostream.o ../libio/pic/isgetline.o ../libio/pic/isgetsb.o 
> ../libio/pic/isscan.o ../libio/pic/osform.o ../libio/pic/procbuf.o 
> ../libio/pic/sbform.o ../libio/pic/sbgetline.o ../libio/pic/sbscan.o 
> ../libio/pic/stdiostream.o ../libio/pic/stdstrbufs.o 
> ../libio/pic/stdstreams.o ../libio/pic/stream.o ../libio/pic/streambuf.o 
> ../libio/pic/strstream.o ../libio/pic/PlotFile.o ../libio/pic/SFile.o 
> ../libio/pic/parsestream.o ../libio/pic/pfstream.o ../libio/pic/editbuf.o 
> ../libiberty/pic/strerror.o -lm -v -lgcc -lc -lgcc 
> /home/fsirl/rh70/gcc295/BUILD/obj-gcc-ppc/gcc/crtendS.o /usr/lib/crtn.o
> /usr/bin/ld: final link failed: Bad value
> GNU ld version 2.11.92.0.7 20011016
> collect2: ld returned 1 exit status

The PPC linker doesn't give a clue when something goes wrong:

   3262                       else if (sec == NULL || sec->owner == NULL)
   3263                         {
   3264                           bfd_set_error (bfd_error_bad_value);
   3265                           return false;
   3266                         }

which I think is a very bad practice. The real problem is ELF/PPC is
trying to handle R_PPC_NONE like a normal relocation. Unfortunately,
it is against the removed linkonce section. I have no idea what is
so special about ELF/PPC that R_PPC_NONE has to be handled that way.

BTW, we need to check all ELF backends to see if they do strange things
to R_XXX_NONE like ELF/PPC.


H.J.

Re: Why deos ELF/PPC care R_PPC_NONE?

[H . J . Lu]

On Thu, Oct 18, 2001 at 12:52:16PM -0700, H . J . Lu wrote:

> The PPC linker doesn't give a clue when something goes wrong:
> 
>    3262                       else if (sec == NULL || sec->owner == NULL)
>    3263                         {
>    3264                           bfd_set_error (bfd_error_bad_value);
>    3265                           return false;
>    3266                         }
> 
> which I think is a very bad practice. The real problem is ELF/PPC is
> trying to handle R_PPC_NONE like a normal relocation. Unfortunately,
> it is against the removed linkonce section. I have no idea what is
> so special about ELF/PPC that R_PPC_NONE has to be handled that way.
> 
> BTW, we need to check all ELF backends to see if they do strange things
> to R_XXX_NONE like ELF/PPC.
> 
> 

This patch seems to work for me.

H.J.
----
2001-10-18  H.J. Lu <hjl@gnu.org>

	* elf32-i370.c (i370_elf_relocate_section): Ignore R_XXX_NONE.
	* elf32-ppc.c (ppc_elf_relocate_section): Likewise.

Index: elf32-i370.c
===================================================================
RCS file: /work/cvs/gnu/binutils/bfd/elf32-i370.c,v
retrieving revision 1.13
diff -u -p -r1.13 elf32-i370.c
--- elf32-i370.c	2001/09/24 00:03:54	1.13
+++ elf32-i370.c	2001/10/18 20:19:00
@@ -1432,6 +1432,9 @@ i370_elf_relocate_section (output_bfd, i
 	  ret = false;
 	  continue;
 
+	case (int)R_I370_NONE:
+	  continue;
+
 	/* Relocations that may need to be propagated if this is a shared
            object.  */
 	case (int)R_I370_REL31:
@@ -1444,7 +1447,6 @@ i370_elf_relocate_section (output_bfd, i
 
 	/* Relocations that always need to be propagated if this is a shared
            object.  */
-	case (int)R_I370_NONE:
 	case (int)R_I370_ADDR31:
 	case (int)R_I370_ADDR16:
 	  if (info->shared)
Index: elf32-ppc.c
===================================================================
RCS file: /work/cvs/gnu/binutils/bfd/elf32-ppc.c,v
retrieving revision 1.26
diff -u -p -r1.26 elf32-ppc.c
--- elf32-ppc.c	2001/10/15 20:55:58	1.26
+++ elf32-ppc.c	2001/10/18 20:19:00
@@ -3128,6 +3128,9 @@ ppc_elf_relocate_section (output_bfd, in
 	  ret = false;
 	  continue;
 
+	case (int) R_PPC_NONE:
+	  continue;
+
 	/* Relocations that need no special processing.  */
 	case (int) R_PPC_LOCAL24PC:
 	  /* It makes no sense to point a local relocation
@@ -3163,7 +3166,6 @@ ppc_elf_relocate_section (output_bfd, in
 
 	/* Relocations that always need to be propagated if this is a shared
            object.  */
-	case (int) R_PPC_NONE:
 	case (int) R_PPC_ADDR32:
 	case (int) R_PPC_ADDR24:
 	case (int) R_PPC_ADDR16:

Re: Why deos ELF/PPC care R_PPC_NONE?

[Alan Modra]

On Thu, Oct 18, 2001 at 01:28:49PM -0700, H . J . Lu wrote:
> 
> 	* elf32-i370.c (i370_elf_relocate_section): Ignore R_XXX_NONE.
> 	* elf32-ppc.c (ppc_elf_relocate_section): Likewise.

I'd call this an "obvious fix", except for the fact that elf32_ppc.c
specifically mentions R_PPC_NONE in the group of relocations "that
always need to be propagated if this is a shared object".  Go ahead
and apply it anyway;  The only real use I can think of for a _NONE
reloc is in tying sections together during --gc-sections, and I don't
think ppc binutils does anything like that.

Alan

Re: The Linux binutils 2.11.92.0.7 is released.

[H . J . Lu]

On Sun, Oct 21, 2001 at 04:48:42PM +0200, Klaus Naumann wrote:
> 
> Hi,
> 
> also with these binutils I still have a problem when compiling mozilla.
> Maybe you know what the issue is ...
> 
> make[2]: Entering directory `/mnt/build/mozilla/mozilla/content/build'
> rm -f libgkcontent.so
> c++ -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion
> -Wpointer-arith -Wbad-function-cast -Wcast-align -Woverloaded-virtual
> -Wsynth -pedantic -Wno-long-long -pthread  -DNDEBUG -DTRIMMED -Wa,-xgot
> -shared -Wl,-h -Wl,libgkcontent.so -o libgkcontent.so  nsContentDLF.o
> nsContentModule.o nsContentHTTPStartup.o    -Wl,--whole-archive
> ../../dist/lib/libgkconevents_s.a ../../dist/lib/libgkconhtmlcon_s.a
> ../../dist/lib/libgkconhtmldoc_s.a ../../dist/lib/libgkconhtmlstyle_s.a
> ../../dist/lib/libgkconxmlcon_s.a ../../dist/lib/libgkconxmldoc_s.a
> ../../dist/lib/libgkconxsldoc_s.a ../../dist/lib/libgkconxulcon_s.a
> ../../dist/lib/libgkconxuldoc_s.a ../../dist/lib/libgkconxultmpl_s.a
> ../../dist/lib/libgkconxbl_s.a ../../dist/lib/libgkconbase_s.a
> ../../dist/lib/libgkconshared_s.a  -Wl,--no-whole-archive -L../../dist/bin
> -lgkgfx -L../../dist/bin -lxpcom -L../../dist/bin
> -L/mnt/build/mozilla/mozilla/dist/lib -lplds4 -lplc4 -lnspr4 -lpthread
> -ldl -lc  -L../../dist/bin -lmozjs
> -Wl,--version-script,../../build/unix/gnu-ld-scripts/components-version-script
> -ldl -lm  -lc

It is a known problem if

1. You don't compile shared libraries with -fpic/-fPIC.
2. Even if you do, you may overflow GOT table.


H.J.

Re: The Linux binutils 2.11.92.0.7 is released.

[H . J . Lu]

On Mon, Oct 22, 2001 at 10:43:00PM +0200, Klaus Naumann wrote:
> > 2. Even if you do, you may overflow GOT table.
> 
> Well, even adding -fpic doesn't help a whole lot.
> What is a GOT table ? And do you see any fix for the problem ?

See

http://sources.redhat.com/ml/binutils/2001-09/msg00299.html



H.J.

Re: The Linux binutils 2.11.92.0.7 is released.

[Ralf Baechle]

On Mon, Oct 22, 2001 at 10:43:00PM +0200, Klaus Naumann wrote:

> > 1. You don't compile shared libraries with -fpic/-fPIC.
> > 2. Even if you do, you may overflow GOT table.
> 
> Well, even adding -fpic doesn't help a whole lot.
> What is a GOT table ? And do you see any fix for the problem ?

-fpic is default on Linux/MIPS and as such adding that option won't have any
effect.

  Ralf

Re: The Linux binutils 2.11.92.0.7 is released.

[Ralf Baechle]

On Tue, Oct 23, 2001 at 02:41:33PM +0200, Klaus Naumann wrote:

> > > > 1. You don't compile shared libraries with -fpic/-fPIC.
> > > > 2. Even if you do, you may overflow GOT table.
> > > 
> > > Well, even adding -fpic doesn't help a whole lot.
> > > What is a GOT table ? And do you see any fix for the problem ?
> > 
> > -fpic is default on Linux/MIPS and as such adding that option won't have any
> > effect.
> 
> I also tried -fPIC . -Wa,-xgot is also the default. -G X doesn't
> change anything ...

-G is not supported with PIC and unless somebody really had his crack
bucketwise or otherwise hates performance -Wa,-xgot isn't default.  ATM
-fPIC is the same as -fpic but this might be changes to imply a large GOT
code model.

  Ralf

Re: The Linux binutils 2.11.92.0.7 is released.

[Ralf Baechle]

On Wed, Oct 24, 2001 at 08:43:35AM +0200, Klaus Naumann wrote:

> So to ask again, there is no other solution than -xgot ?
> And if that's the only solution, what are the issues ? Only bigger code ?

Alternative solutions would require significant work on binutils.

  Ralf