|
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
[Prev in Thread] | Current Thread | [Next in Thread] |