This is the mail archive of the
mailing list for the binutils project.
RE: [GOLD] common symbol resolution
Don't look at this as using something against you. I am just trying to
do the right thing and used a google search to try and find some rules.
I thought I found the rules spelled out by you.
What are the formal Gold relocation rules? It can't be the code because
there is no way to detect what is gospel and what is a bug. I need to know
because I am tasked with passing the ld tests with the gold linker so we
can replace ld with gold.
From: Ian Lance Taylor [email@example.com]
Sent: Friday, May 11, 2012 11:23 PM
To: Carter, Jack
Subject: Re: [GOLD] common symbol resolution
Jack Carter <firstname.lastname@example.org> writes:
> I am running the Mips build of the gold linker on the "Common symbol
> override" test.
> For the scenario when the .o has a COMMON symbol and the shared object
> it is linked against has the symbol defined. I believe the a.out is
> suppose to have the symbol as an UNDEF.
> See http://www.scribd.com/doc/89505704/19/Symbol-Resolution #9
> It looks to me that the gold linker is set up to either override the
> target symbols attribute or keep it what it was. My output has the
> symbol in the a.out becoming a DEF.
Unfortunately it's ineffective to quote my own words against me, as I
reserve the right to change my mind. It's also interesting that
somebody has pulled my words out of my blog and put them on an ad
supported web site, especially since I already host them on my own ad
supported web site, in this case at http://www.airs.com/blog/archives/49.
Anyhow, in that blog entry I was describing how the GNU linker handles
symbol resolution. When writing gold I looked at it from a different
point of view, and I was not convinced that the approach used in the GNU
linker was right. I think the GNU linker originally permitted a defined
symbol in a shared library to override a common symbol in the
executable. However, that led to trouble, so the GNU linker was changed
such that only a STT_OBJECT symbol in a shared library would override
the executable; an STT_FUNCTION symbol would not. I think this suggests
strongly that the GNU linker started in the wrong direction, and that a
shared library definition should not override a regular common symbol.
Unfortunately the ELF ABI is silent on the matter.
> Is there a clean and easy way to just modify the output symbol
> attributes by hand.
> reloc.cc: Symbol_table::should_override(...)
> case WEAK_DEF * 16 + COMMON:
> case DYN_DEF * 16 + COMMON:
> case DYN_WEAK_DEF * 16 + COMMON:
> // A common symbol does override a weak definition or a dynamic
> // definition.
> return true;
> and then calls
> My first attempt to fix this was to hack Symbol_table::override(). That
> got ugly quickly and I still wasn't changing the output attributes of
> the symbol.
You shouldn't have to change Symbol_table::override, you should just
change the return value of Symbol_table::should_override. Note that the
case you quote above is the unusual case where the linker first sees a
definition in a shared library and then sees a common symbol in a
regular object file. You are probably more interested in
case COMMON * 16 + DYN_DEF:
case WEAK_COMMON * 16 + DYN_DEF:
case DYN_COMMON * 16 + DYN_DEF:
case DYN_WEAK_COMMON * 16 + DYN_DEF:
// Ignore a dynamic definition if we already have a common
and you probably just want that to return true.