[PATCH] elf: Re-initialise static TLS after .tdata relocation (BZ 34164)

Adhemerval Zanella Netto adhemerval.zanella@linaro.org
Tue May 26 23:03:42 GMT 2026



On 26/05/26 19:57, H.J. Lu wrote:
> On Wed, May 27, 2026 at 6:50 AM Adhemerval Zanella Netto
> <adhemerval.zanella@linaro.org> wrote:
>>
>>
>>
>> On 26/05/26 19:47, H.J. Lu wrote:
>>> On Wed, May 27, 2026 at 6:39 AM Adhemerval Zanella Netto
>>> <adhemerval.zanella@linaro.org> wrote:
>>>>
>>>>
>>>>
>>>> On 26/05/26 18:36, H.J. Lu wrote:
>>>>> On Wed, May 27, 2026 at 2:52 AM Adhemerval Zanella
>>>>> <adhemerval.zanella@linaro.org> wrote:
>>>>>>
>>>>>> The af34b1376a37fa27e1de9d869ed9493fc569bfa6 changed the .tdata
>>>>>> setup from:
>>>>>>
>>>>>>   relocation loop (applies relocations to .tdata in DSO memory)
>>>>>>   _dl_allocate_tls_init copies relocated .tdata -> main thread TLS
>>>>>>
>>>>>> to a new order:
>>>>>>
>>>>>>   _dl_allocate_tls_init copies unrelocated .tdata -> main thread TLS
>>>>>>   relocation loop (relocates .tdata in DSO memory, but the TLS block
>>>>>>   has stale copies)
>>>>>>
>>>>>> This broke file-scope thread-local initialised with the address of a
>>>>>> function (for instance the cache structs in libmpfr).
>>>>>
>>>>> This is a regression.  Please file a glibc bug report.
>>>>
>>>> I think there is no need to file a bug report, it is a regression for
>>>> an unreleased version and it is really related to BZ#34164.
>>>
>>> If it is related to BZ #34164, please update BZ #34164 and mention it
>>> in the commit message.
>>
>> It is with af34b1376a37fa27e1de9d869ed9493fc569bfa6 mention, the commit that
>> introduced this regression.  I think the commit message has all the information
>> to track when, why, and how the issue was introduced.
> 
> Mention BZ #34164 makes the potential backport easier.
Ack.


More information about the Libc-alpha mailing list