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

[Frank Scheiner]

Dear Florian,

On 30.12.24 10:47, Florian Weimer wrote:
> * 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.

Thanks for the suggestions. I had a look around (also in the IA-64 docs)
but I don't really like to change these details in a way that would
contradict the existing documentation for ia64. Also - more decisive - I
don't really know how to do it - yet. :-)

> 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.

Maybe it could be done easier then.

Cheers,
Frank