Re: PATCH for i386: --no-copy-relocs

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

"H . J . Lu" <hjl@lucon.org> writes:

> On Thu, Jun 21, 2001 at 01:55:38PM -0700, Ian Lance Taylor wrote:
> > > 
> > > I see. So if the main executable is compiled with PIC, should the
> > > linker still generate the COPY reloc?
> > 
> > A program compiled PIC normally does not require a reloc in the text
> > segment.  So normally the COPY reloc is not needed in such a case.
> > 
> > That suggests the possibility of changing the linker to only generate
> > a COPY reloc for a symbol which is referenced from a SEC_READONLY
> > section.  For example, this will currently generate a COPY reloc if i
> > is defined in a shared library:
> > 
> > extern int i;
> > int *p = &i;
> > 
> > However, the COPY reloc in this case does not help eliminate
> > relocations from the text segment, and in fact serves no terribly
> > useful purpose.  It would be just as good to keep the reloc for p in
> > the data segment as it is to generate the COPY reloc for i.
> > 
> > Similarly, I agree that if a GLOB_DAT relocation is required for i
> > (e.g. it is referred to by PIC code) and there are no other references
> > to i from the text section, then as far as I can see adding a COPY
> > reloc serves no purpose.
> 
> Even if we don't generate R_386_COPY for `i', it still doesn't work
> since we will put `i' in the .bss section of the main exectuable. Since
> DSO is built with -Wl,-Bsymbolic, updating `i' in DSO won't change
> `i' in the main exectuable.

That is how it works now, but it does not have to work that way.
Because `i' is not a common symbol, we do not have to put it in the
.bss section.  We can just leave it as an external reference with
dynamic relocations, and let the dynamic linker handle the relocations
at runtime.  That will cause the main executable to use the address of
`i' in the data segment of the shared library.

Ian