This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


> 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>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]