Re: Specification of ELF symbol versioning

[Florian Weimer <fw at deneb dot enyo dot de>]

* Carlos O'Donell:

> On Sun, Oct 9, 2016 at 9:02 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
>> There is this document:
>>
>>   <https://www.akkadia.org/drepper/symbol-versioning>
>>
>> But it has a few obvious issues: “vna_other” is not unused, as

The description of “vna_other” seems bogus, too: The document says “If
the highest bit (bit 15) is set this is a hidden symbol which cannot
be referenced from outside the object.”  I think this describes the
versym section entries instead.  Only there, the non-default version
indices have their most significant bit set.  verdef entries do not;
the advantage is that you do not need two distinct verdef entries to
support symbol versions which have both default and non-default
versions at this version.

>> indicated in the comment, and “vn_name” is mentioned but never defined
>> (perhaps “vn_file” is meant instead).
>>
>> Is there a better document which described which is or should be
>> implemented in the static and dynamic linker?
>
> No.
>
> Unless you count the document that will be written by you and I in the
> future? ;-)

I came across this issue because I wanted to correct the SQL modeling
of symbol versioning in symboldb.

My initial goal was to determine whether the version indices have
semantic meaning (beyond 0, 1, and perhaps 2).

I came across this old bug report after validating the odd dlsym
behavior:

  <https://sourceware.org/bugzilla/show_bug.cgi?id=12977>

Thinking more about this, I'm pretty sure this is a glibc bug after
all.  For the non-versioned binding against a versioned symbol, the
dynamic linker should really pick the symbol with the lowest version
index (1 or 2, including hidden definitions), or for dlsym, the first
non-hidden symbol (the “default version”, there should be only one).

Another important question is whether GNU-style symbol version offers
functionality comparable to “-B direct” in the solaris linker.
Version references contain a soname, and we could bind this soname to
a *single* DSO at load time.  Then we just have to look at objects
defining any unversioned symbols, plus the one DSO that is named in
the version reference.  The specification is silent on this matter.