[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Rod Evans
Subject: Re: [osol-discuss] Re: GNU ld -shared fails to link filtered symbols on Solaris
Date: Mon, 27 Nov 2006 21:38:29 -0800
User-agent: Thunderbird (X11/20060814)

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]