[new test case jluu@mainsoft.com: Re: Possible linker problem]

[Geoff Keating]

> From: "Jose Luu" <jluu@mainsoft.com>
> Cc: <binutils@sourceware.cygnus.com>
> Date: Tue, 14 Mar 2000 19:40:44 +0100

> The executable is referencing a symbol in the shared library with no intent
> to override (declared as external int).
> 
> The shared library is linked with Bsymbolic.
> 
> The result is that the said symbol also becomes defined in the executable,
> so we have 2 symbols with the same name and the confusion that results.

I see.  The problem is that the executable has the address of the
variable hard-coded and so uses a R_*_COPY reloc; but the dso also
'knows' where the variable is and doesn't have the information in
relocs to let the symbol be in the executable.

eg. on ppc the following DSO:

int foo = 3;
int getfoo(void) { return foo; }

generates the following relocs:

DYNAMIC RELOCATION RECORDS
OFFSET   TYPE              VALUE 
000405c8 R_PPC_RELATIVE    *ABS*+0x0004065c
00040670 R_PPC_RELATIVE    *ABS*+0x000405cc
0004066c R_PPC_RELATIVE    *ABS*+0x000405c8
00040674 R_PPC_RELATIVE    *ABS*+0x00040654
00040678 R_PPC_RELATIVE    *ABS*+0x00040680

but it needs to explicitly have relocs against 'foo', like this:

00040674 R_PPC_GLOB_DAT    foo

because 'foo' might be in the executable.

There is probably a similar problem with taking the address of functions.

This should actually simplify 'ld' a bit, because much of the
special-case handling for -Bsymbolic should probably go away; the
handling must happen in ld.so instead (hopefully ld.so handles it
right).

-- 
- Geoffrey Keating <geoffk@cygnus.com>