Re: [osol-discuss] Re: GNU ld -shared fails to link filtered symbols on Solaris
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 ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [osol-discuss] Re: GNU ld -shared fails to link filtered symbols on Solaris
Alan Modra wrote:
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.)
An ABS symbol is absolute, and shouldn't change through relocation of
the object that contains the ABS symbol. But, I don't think another
object should inherit this ABS status.
If I reference an ABS symbol foo, in libfoo.so.1, and the value is
0x1234, then at runtime I should bind to that ABS symbol and be
directed to address 0x1234. If the shared object is later redelivered
with an ABS value of 0x5678, then at runtime, I should bind to, and be
directed to the new address 0x5678. I shouldn't have to relink my
caller to obtain this new address. Under the same logic, I should
be able to redeliver libfoo with a definition of foo that is no
longer ABS.
The caller should bind to the definition in an appropriate manner -
FUNC's typically result in the generation of .plts, data references
perhaps .gots. The symbols section index (SHN_) typically isn't
a factor in establishing the binding model.
Anyway, the above is how the Solaris ld(1) handles these symbols.
We've just used them as part of our filtering mechanism. I don't
think we generate ABS anywhere else, as all symbols are typically
associated with some backing storage.
We could produce a filter from a c stub. For example, an empty
function like:
void foo() {}
would result in a non-ABS symbol, and a little .text. If this
symbol was also tagged as a filter, then the functions implementation
would never be called - the runtime redirection to the filtee
would have kicked in and bypassed this definition. So, rather than
create wasted no-ops like this, we allow the creation of a filter
symbol directly from a mapfile - this has no backing storage, hence
the ABS index being assigned to the symbol.
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.
Well, I'm not very familiar with the gnu linker, but Martins experiments
seem to suggest that the treatment of an ABS definition is inconsistent -
sometimes they result in UNDEF references, other times ABS.
Martin might have to add some c stub functions to his builds so that
his libraries provide non-ABS filter symbols in the mean time.
--
Rod
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [osol-discuss] Re: GNU ld -shared fails to link filtered symbols on Solaris
Rod Evans wrote:
Martin might have to add some c stub functions to his builds so that
his libraries provide non-ABS filter symbols in the mean time.
Arrr, but then the gnu linker probably doesn't grok symbol filter
definitions from a mapfile, so the sc tub trick wouldn't provide
much use would it. Sorry.
chaz 940.. cat xxx.c
void foo(){}
int bar = 1;
chaz 941.. cat mapfile
{
global:
foo = FILTER yyy.so;
bar = FILTER yyy.so;
};
chaz 942.. cc -G -o xxx xxx.c -Mmapfile
chaz 943.. elfdump -y xxx | egrep "bound|foo|bar"
index flagsbound to symbol
[6] F[0] yyy.so bar
[7] F[0] yyy.so foo
chaz 944.. elfdump -sN.dynsym xxx | egrep "foo|bar"
[6] 0x000103b0 0x0004 OBJT GLOB D0 .data bar
[7] 0x02d0 0x0005 FUNC GLOB D0 .text foo
--
Rod
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [osol-discuss] Re: GNU ld -shared fails to link filtered symbols on Solaris
Joerg Schilling wrote: This may still not prove your claim as the final ELF spec has been done by Sun and AT&T as part of the the joined work for SVr4. The original ELF spec was indeed created by these players. But, the design allowed for a great deal of extensibility. All of the UN*X's have added their own extensions. The various players have also done a great deal of collaboration to share each others extensions, or at least carve out name spaces such that we don't step on each others toes. It's not a perfect world, but the original designers did a pretty good job. The format has allowed for many innovations while still providing backward compatibility. So, I don't believe there is *an* owner. There are numerous specifications maintained by various bodies that document the core format together with various extensions. The Solaris definition is maintained in the "Object File Format" chapter of the Linker and Libraries Guide: http://docs.sun.com/app/docs/doc/817-1984/6mhm7pl26?a=view -- Rod. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
