Re: Copy relocations against versioned symbols with aliases without a default version

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Tue, Mar 7, 2017 at 6:57 AM, Florian Weimer <fweimer@redhat.com> wrote:
> I'm trying to clean up the timezone code in glibc.  Historically, we export
> both tzname and __tzname, and the symbols are aliased:
>
>    271: 0000000000399380    16 OBJECT  GLOBAL DEFAULT   33
> __tzname@@GLIBC_2.2.5
>    589: 0000000000399380    16 OBJECT  WEAK   DEFAULT   33
> tzname@@GLIBC_2.2.5
>
> __tzname was exported more or less by accident, so I want to turn it into a
> compat symbol, resulting in:
>
>    271: 0000000000399380    16 OBJECT  GLOBAL DEFAULT   33
> __tzname@GLIBC_2.2.5
>    589: 0000000000399380    16 OBJECT  WEAK   DEFAULT   33
> tzname@@GLIBC_2.2.5
>
> When linking an object file with an R_X86_64_32S relocation against tzname
>
>   bb:   4d 8b 64 dd 00          mov    0x0(%r13,%rbx,8),%r12
>   c0:   48 8b 2c dd 00 00 00    mov    0x0(,%rbx,8),%rbp
>   c7:   00
>                         c4: R_X86_64_32S        tzname
>   c8:   4c 89 e6                mov    %r12,%rsi
>
> to this variant, I get this error:
>
> /usr/bin/ld: …/tst-timezone.o(.text+0xc4): unresolvable R_X86_64_32S
> relocation against symbol `tzname@@GLIBC_2.2.5'
>
> This is really unexpected.  It seems that something causes the hidden bit to
> be set on the compat symbol version for __tzname.  I assume ld treats this
> as an indication that a hidden alias symbol exists, so that it cannot create
> a copy relocation without breaking the alias.
>
> This is really fishy.  The hidden bit is documented as “If the highest bit
> (bit 15) is set this is a hidden symbol which cannot be referenced from
> outside the object.” in <https://www.akkadia.org/drepper/symbol-versioning>,
> but this is not what is implemented because references to these
> supposedly-hidden symbols work just fine if you specify an explicit symbol
> version, both at static link time and at run time (which is not something we
> can change in the dynamic linker because we have many existing binaries
> which use hidden symbol versions for supposedly-exported non-default compat
> symbols).  So there is no real reason why the static linker has to refuse to
> create a copy relocation in such a cases.
>
> Comments?

Do you have a standalone testcase?

-- 
H.J.