Why deos ELF/PPC care R_PPC_NONE?

["H . J . Lu" <hjl at lucon dot org>]

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.