[PATCH] elf: Check multiple definition when defining hidden version

[Fangrui Song]

On 2020-12-03, H.J. Lu via Binutils wrote:
>On Thu, Dec 3, 2020 at 4:22 PM Alan Modra <amodra@gmail.com> wrote:
>>
>> On Thu, Dec 03, 2020 at 05:10:51AM -0800, H.J. Lu wrote:
>> > What your patch does are
>> >
>> > 1. Hide the weak foo@@v1.
>> > 2. Change the non-weak, hidden foo@v1 to the default foo@@v1.
>>
>> Yes, and that is what gold does currently too.
>>
>> > It is the opposite of what @@ and @ are supposed to do.  I believe we
>> > should reject such inputs.
>>
>> It would seem that you and I have a slightly different idea of what @@
>> and @ mean.  I expect we'd agree on most of the normal use of symbol
>> versioning, but I don't see any reason to consider the result of my ld
>> fix the "opposite of what @@ and @ are supposed to do".  The mere fact
>> that you claim that makes me suspect you haven't spent much time
>> thinking about the problem.
>
>My comments are based on my work with symbol versioning in glibc.
>
>> So I'm going to commit my patch for this PR.
>
>Instead of refusing to accept dubious inputs, ld now may generate incorrect
>outputs which may be hard to track down.
>
>FWIW, I will revert this patch in my own linker.
>
>> PS: For anyone reading this mailing list and wondering about versioned
>> symbols, I recommend Ian's excellent blog posts.  Searching
>> "site:airs.com symbol version" will give you more than one article
>> worth reading.

If I read Alan's patch correctly, the semantics make sense to me: strong
override weak and @@ (default version) is an additional bit which will
be attached to the prevailing definition.

FWIW I suspect that gold/symtab.cc Symbol_table::define_default_version
(which handles the "combining versions" issue) has some unneeded logic,
but I haven't investigated further.

I have mentioned other 2 symbol versioning problems in https://maskray.me/blog/2020-11-26-all-about-symbol-versioning

* https://sourceware.org/pipermail/binutils/2020-April/110622.html
   "V4 [PATCH] gas: Extend .symver directive"

   This one looks quite good to me, if we cannot re-purpose `.symver foo, foo@v1`,
   `.symver foo, foo@v1, remove` may be fine, though I'll probably prefer
   `.symver foo, foo@v1, rename` 

   Another choice is to design a directive instead of adding new
   semantics to the broken .symver (don't inherit binding/st_other/etc
   for the new directive)

* https://sourceware.org/bugzilla/show_bug.cgi?id=24718#c15
   Make VER_FLG_WEAK meaningful