bug-binutils
[Top][All Lists]
Advanced

[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 17:52:08 -0800
User-agent: Thunderbird 1.5.0.5 (X11/20060814)

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.

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

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.

--
Rod




reply via email to

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