[osol-discuss] Re: GNU ld -shared fails to link filtered symbols on Solaris

Rod Evans Rod.Evans@Sun.com
Tue Nov 28 05:38:00 GMT 2006

Alan Modra wrote:

>> The question, I think, is why the ABS state of the symbol *definition* is
>> inherited by the symbol state of the *reference*.  A reference is
>> typically undefined (UNDEF).
> Perhaps because the Sys V ABI says:
>     The symbol has an absolute value that will not change because of
>     relocation.
> From that wording, I don't think it unreasonable that an ABS symbol
> in a shared lib should serve as directly defining the value of a
> reference outside that lib.  (I don't think it's a particularly good
> or useful way to treat ABS symbols in shared libs, but maybe I just
> haven't thought enough.)

An ABS symbol is absolute, and shouldn't change through relocation of
the object that contains the ABS symbol.  But, I don't think another
object should inherit this ABS status.

If I reference an ABS symbol foo, in libfoo.so.1, and the value is
0x1234, then at runtime I should bind to that ABS symbol and be
directed to address 0x1234.  If the shared object is later redelivered
with an ABS value of 0x5678, then at runtime, I should bind to, and be
directed to the new address 0x5678.  I shouldn't have to relink my
caller to obtain this new address.  Under the same logic, I should
be able to redeliver libfoo with a definition of foo that is no
longer ABS.

The caller should bind to the definition in an appropriate manner -
FUNC's typically result in the generation of .plts, data references
perhaps .gots.  The symbols section index (SHN_) typically isn't
a factor in establishing the binding model.

Anyway, the above is how the Solaris ld(1) handles these symbols.
We've just used them as part of our filtering mechanism.  I don't
think we generate ABS anywhere else, as all symbols are typically
associated with some backing storage.

We could produce a filter from a c stub.  For example, an empty
function like:

	void foo() {}

would result in a non-ABS symbol, and a little .text.  If this
symbol was also tagged as a filter, then the functions implementation
would never be called - the runtime redirection to the filtee
would have kicked in and bypassed this definition.  So, rather than
create wasted no-ops like this, we allow the creation of a filter
symbol directly from a mapfile - this has no backing storage, hence
the ABS index being assigned to the symbol.

>> With an UNDEF reference, a binding should be established to the
>> definition at runtime.  At that point it is the responsibility of the
>> runtime linker to enable any filtering.
>> When the Solaris linker (ld(1)) builds an object which expresses a
>> filter as a dependency, the linker simply reads the symbol table as
>> it would any other shared object.  .plt's and .gots are created
>> where necessary to form the bindings to the destination function or
>> data item.  ld(1) doesn't know, or care, that the object to which it
>> is establishing a binding is a filter.  The filtering is all taken
>> care of a runtime.
> You seem to want some other sort of treatment of ABS symbols, as
> needing .plt or .got entries, I presume.  I think that might be OK
> too, but may require some redesign of GNU ld.  The trouble is that
> GNU ld has just one ABS section internally.  That means that ABS
> symbols are lumped together and lose their association with a
> particular object file.  I'm reasonably certain that this will cause
> you some trouble.

Well, I'm not very familiar with the gnu linker, but Martins experiments
seem to suggest that the treatment of an ABS definition is inconsistent -
sometimes they result in UNDEF references, other times ABS.

Martin might have to add some c stub functions to his builds so that
his libraries provide non-ABS filter symbols in the mean time.


More information about the Binutils mailing list