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:
SHN_ABS
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.)
> 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
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
