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 04:33:08PM -0700, Ian Lance Taylor wrote:
> > > 
> > > 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.
> 
> I have a few questions:
> 
> 1. Which dynamic relocations do you suggest we use? They have to deal
> with R_386_GOT32 and R_386_32.

I don't suggest that you use any new dynamic relocations.

Right now for something like `int *p = &i', the object file will have
an R_386_32 reloc for `i' in the data section.  When the object file
is linked with a shared library, which defines `i', space for `i' will
be allocated in the main executable, the R_386_32 relocation will be
resolved against the allocated space, and an R_386_COPY relocation
will be generated to initialize the allocated space.

Instead, we can simply the R_386_32 relocation in place, not allocate
space for `i' in the main executable, and not generate the R_386_COPY
relocation.  The dynamic linker will resolve the R_386_32 relocation
against the version of `i' defined in the shared library.

> 2. Should we do it for all DSOs or just DSOs compiled with -Bsymbolic?

This is an operation which would be done when linking the main
executable, not when linking the shared library.  It could be done in
all cases.

> 3. Since we don't know what runtime DSO will be used, there will be
> mismatch between link-time and run-time regarding -Bsymbolic.

This is a confusion.  What I am suggesting is a change which is
semantically neutral.  It is always OK to not generate a COPY reloc
for an undefined symbol and to instead leave the relocation in the
main executable.

The COPY reloc is an optimization which permits text sections to be
shared.  Omitting the COPY relocation is always OK if you don't care
whether text sections are shared.  If a symbol is only referenced from
writable sections, then omitting the COPY relocation is OK because
those sections can not be shared anyhow.

Ian