bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/24718] BFD ld does not set VER_FLG_WEAK on version reference if


From: carlos at redhat dot com
Subject: [Bug ld/24718] BFD ld does not set VER_FLG_WEAK on version reference if all symbols are weak
Date: Mon, 24 Jun 2019 16:47:53 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=24718

--- Comment #13 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Florian Weimer from comment #12)
> <https://www.akkadia.org/drepper/symbol-versioning> says this:
> 
>   vna_flags
>    Bitmask of flags.  Currently the following are defined:
> 
>      VER_FLG_WEAK     the reference to this version is weak.

This specification was written and implemented before the glibc community
corrected their interpretation of the ELF standard and introduced
LD_DYNAMIC_WEAK to undo similar weak-style changes. That is to say that the
VER_FLG_WEAK description in "symbol-vresioning" is based on an incorrect
interpretation of the ELF standard. It was based on the idea that you would
scan all loaded shared objects for a potentially strong definition that
overrode the weak one, and you can see this means lazy loading would be useless
in this case because even one weak symbol means you need to load *everything*
to confirm no strong symbols override.

See "Weak symbols that aren't"
https://lists.x.org/archives/xorg/2006-August/017341.html
https://sourceware.org/ml/libc-hacker/2000-06/msg00029.html

Weak Symbol - Limitations
https://en.wikipedia.org/wiki/Weak_symbol#Limitations

Thus the only use left for VER_FLG_WEAK is the usage as described in the
Solaris documentation.

> I believe this is what is implemented in glibc, but it's not bean tested so
> far because binutils doesn't set this flag.  It should be quite safe to
> introduce this feature in binutils (obviously for GNU only).

It is because it is a historical implementation. We could deprecate
LD_DYANMIC_WEAK and remove lots of code and simplify things.

> The Solaris documentation is not helpful at all in this case because our
> implementation is so very different.  Based on reading that documentation,
> Solaris does not bind individual symbols to versions, only shared object
> dependencies as a whole. 

Correct, and if we wanted we could implement the Solaris meaning of
VER_FLG_WEAK for "weak version definitions." I don't know how we would instruct
a binding between the binary and the "weak version definition", some new linker
file construct like Solaris has.

> Therefore, the problem that weak symbol references
> try to solve in Ulrich's approach does not actually arise on Solaris. 

Correct, because weak *symbol* references don't exist in Solaris, only
references to versions, and those version definitions can be weak.

I think the original "symbol-versioning" design simply tried to carry the
static linker semantics of weak symbol version processing to the dynamic linker
without consideration for the impact it would have on lazy binding. Namely that
if you have an undefined weak reference to a symbol, you have to search every
object looking for a potential strong reference, instead of stopping at the
first definition (weak or strong) that you find based on search order.

> Instead, you can just instruct the link editor to omit certain symbol
> version references from the resulting binary, keep a weak (unversioned)
> symbol reference, and apply a run-time check, as with any weak symbol.
> Since it is not possible to define multiple symbol versions for the same
> symbol name on Solaris, restricting the set of bound symbol versions at
> static link time is safe.  (In the GNU implementation, this is unsafe
> because different versioned symbols can require different declarations and
> have different behavior in general, so deferring this decision to the link
> editor does not work.)

I don't follow what you're trying to state here. Can you expand on this with an
exmaple please?

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

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