Re: [GOLD] common symbol resolution

[Ian Lance Taylor <iant at google dot com>]

Jack Carter <jcarter@mips.com> 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::resolve(...) 
>
> calls
>
> 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
>
> this->override(...)
>
> 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
      // definition.
      return false;

and you probably just want that to return true.

Ian