[PATCH 0/3] Allow LLD 13.0.0 and improve compatibility with gold and clang

[Siddhesh Poyarekar]

On 7/26/21 9:27 AM, Fangrui Song via Libc-alpha wrote:
> For malloc/tst-compathooks-on,
> 
>      malloc/tst-compathooks-on: Symbol `__free_hook' has different size in shared object, consider re-linking
> 
> the root cause is that lld's symbol versioning is different from GNU ld in an unusal case:
> 
>      __asm__ (".symver " "__free_hook" "," "__free_hook" "@" "GLIBC_2.2.5");
> 
> This leaves two symbols __free_hook and __free_hook@GLIBC_2.2.5.
> __free_hook is then attached a default version GLIBC_2.2.5.
> I think malloc/malloc-debug.c uses a fragile versioned symbol here.
> If the inline asm uses @@ the failure should go away.

The entire point of link time deprecation is to not emit a @@ symbol. 
If lld emits __free_hook@@GLIBC_2.2.5 in this case then this needs to be 
resolved.  How does one do symbol deprecation in lld?

> In summary, I think the failed tests touch some dark corners of the toolchain.
> These things do not really matter for real world applications.

Not having a default symbol version is a documented mechanism[1] to 
deprecate symbols, so this is not some obscure use case.  Symbol 
deprecation matters for real world applications.

Siddhesh

[1] See section 3.3 in https://www.akkadia.org/drepper/dsohowto.pdf:

"Every versioned DSO has at most one version
of every API which can be used at link-time. An API
(not ABI) can also vanish completely: this is a way to
deprecate APIs without affecting binary compatibility."