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

[Rod Evans <Rod dot Evans at Sun dot com>]

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