[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: Alan Modra
Subject: Re: [osol-discuss] Re: GNU ld -shared fails to link filtered symbols on Solaris
Date: Tue, 28 Nov 2006 14:40:43 +1030
User-agent: Mutt/1.5.9i

On Mon, Nov 27, 2006 at 05:52:08PM -0800, Rod Evans wrote:
> Alan Modra wrote:
> >On Mon, Nov 27, 2006 at 10:04:42PM +0100, Martin Man wrote:
> >>There seems to be a bug in GNU ld that does not link filter symbols 
> >>properly.
> >
> >I'd hardly call it a bug.  By the sound of things, Sun has made some
> >extensions to ELF that GNU ld doesn't understand.  Someone (you
> >perhaps) needs to teach GNU ld about the proper handling of these
> >"filter symbols".
> I don't think the issue is "filter symbols" (?).  Solaris implements
> filtering with a combination of symbol table entries and associated
> Syminfo section entries.  The symbol table entries for filter symbols
> are ABS, simply because there's no backing implementation to the symbol
> within the same file.  You can't tell, just from the symbol table entry,
> that the symbol represents a filter - that's a Solaris runtime
> abstraction.

Well, OK.

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

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

Alan Modra
IBM OzLabs - Linux Technology Centre

reply via email to

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