Re: The problem with linkonce sections in ELF

[Ian Lance Taylor <ian at zembu dot com>]

   Date: Tue, 1 Feb 2000 20:55:36 -0800
   From: "H . J . Lu" <hjl@lucon.org>

   >    > Leaving a hole in the address space is clearly a bug.  Your patch
   >    > should not be necessary.  Why are these sections being created with a
   >    > non-zero size, and then being removed?  That makes no sense.
   > 
   >    I was given some .o files with .rel.text sections and linker
   >    removes them when generating DSO with -Bsymbolic.
   > 
   > .rel.text section normally hold relocations.  The linker expects them
   > to do so.  Do these .rel.text sections hold relocations?  If they do,
   > then naturally the linker will remove them, just as it removes all
   > relocation sections.

   Yes. Those rel.text sections do hold relocations. But the .o files are
   not compiled with -fPIC. Without -Bsymbolic, linker will create/copy
   those .rel.text sections in the resulting DSO. With -Bsymbolic, those
   .rel.text sections seem to be removed. The Solaris/x86 linker generates
   the .rel.text section with and without -Bsymbolic. I will check why
   those .rel.text sections are removed.

The .rel.text sections themselves are not really copied.  The linker
removes them, and then creates a new .rel.text section.  The new
section will be created if there are relocations which need to be
copied into the shared library.  The linker doesn't need to copy GOT
or PLT relocations, since they are always position independent.

This copying of relocs is set up in the check_relocs routine.

When using -Bsymbolic, the linker doesn't have to copy any PC relative
relocations which are against symbols which are defined in the shared
library itself.  Without -Bsymbolic, it needs to copy those
relocations, because the symbol might be defined in another object at
runtime.

There are a couple of different places where the linker handles
copying relocations.  Perhaps it is using a different set of
conditions in different places, leading to confusion.  I'm not sure
why it would wind up creating holes in the address space, though.

Ian