[PATCH] elf: Remove the GET_ADDR_ARGS and related macros from the TLS code

[Florian Weimer]

* Frank Scheiner:

> Dear Florian,
>
> On 23.12.24 15:32, Florian Weimer wrote:
>> This was used to manage an IA-64 ABI divergence is no longere needed
>> after the IA-64 removal.
>>
>> (It should be possible to encode all the required information in
>> one machine word, so the pointer indirection is really unnecessary.
>> Technically, none of this is part of the ABI, so perhaps it's
>> possible to do this retroactively.  See bug 27404.)
>
> So this breaks our toolchain builds for ia64 ([1]) - as expected.
>
> [1]: https://github.com/linux-ia64/glibc-ia64/issues/7
>
> I am trying to "fix" that in a way that keeps the changes active for
> architectures other than ia64 but at the same time keeps the builds for
> ia64 working.
>
> I also looked at [2] but I don't know if ia64 can be switched over to
> using the "generic" __tls_get_addr() with single tls_index struct instead
> of two arguments. I guess not, otherwise it would have been implemented
> differently from the start maybe.
>
> [2]: https://sourceware.org/pipermail/libc-alpha/2024-December/163165.html

I think that would be an ABI bump.

You could try to emulate what i386 and s390x do to implement alternative
__tls_get_addr ABIs.  Your wrapper would have to create the TLS
descriptor structure on the stack and pass its address to the shared
glibc implementation.

In the long term, we plan to switch to descriptors using a single
machine word, without indirection.  This is closer to what ia64 did,
except that it only uses one __tls_get_addr argument, not two.

Thanks,
Florian