This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: [new test case jluu@mainsoft.com: Re: Possible linker problem]
- To: jluu at mainsoft dot com
- Subject: Re: [new test case jluu@mainsoft.com: Re: Possible linker problem]
- From: Geoff Keating <geoffk at cygnus dot com>
- Date: Tue, 14 Mar 2000 14:07:32 -0800
- CC: ian at zembu dot com, hjl at lucon dot org, binutils at sourceware dot cygnus dot com
- References: <028201bf8de4$ce8c62f0$2a0da8c0@fred.mainsoft.com>
> 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>