[PATCH v16 2/8] Add generic 'extra TLS'

[Florian Weimer]

* Mathieu Desnoyers:

> On 2025-01-11 09:51, Florian Weimer wrote:
>> This goes wrong on aarch64, resulting in a elf/tst-tlsalign-static
>> failure:
>> tdata1 TLS address 0xaaaac60e9014 % 4 = 0
>> tdata2 TLS address 0xaaaac60e9010 % 16 = 0
>> tdata3 TLS address 0xaaaac60e9000 % 4096 = 0
>> tbss1 TLS address 0xaaaac60ea014 % 4 = 0
>> tbss2 TLS address 0xaaaac60ea010 % 16 = 0
>> tbss3 TLS address 0xaaaac60ea000 % 4096 = 0
>> tbss3 value 24 should be 0
>> Or crash with segmentation fault because rseq_cs is wrong.
>> What seems to happen is that the TLS block (including the rseq area)
>> overlaps with the start of the sbrk heap.  So we are either allocating
>> to little memory for the TLS block, or alignment procedure move things
>> too far away from the start of the allocation.  But I've been staring at
>> it for a while, and I just don't see the bug. 8-(
>
> There is a significant allocation layout change in this patch between
> v15:
>
> https://sourceware.org/pipermail/libc-alpha/2025-January/163619.html
>
> and v16 (last version committed):
>
> https://sourceware.org/pipermail/libc-alpha/2025-January/163718.html
>
> As explained by the second item in the Changes:
>
> Changes since v15:
> - Improve comments around size and alignment calculations
> - Simplify tls_blocks_size calculations
> - Make sure we don't roundup to zero alignment
>
> I suspect something may be wrong with the "Simplify tls_blocks_size
> calculations" changes introduced in v16.

Not sure yet.

I was super-confused for a while about this part:

  /* Record the tcb_offset including the aligment requirements of 'memsz'
     that comes after it.  */
  tcb_offset = roundup (TLS_INIT_TCB_SIZE, align ?: 1);

It's been there before, so I was wondering if the rseq changes merely
exposed a pre-existing bug.  But that doesn't seem to be the case here:
the link editor actually has code to round up its version of
TLS_INIT_TCB_SIZE to the p_align value, and the instructions in the test
binary have the right offset (>= 4096) in the test binary.  This is
quite odd and a bit wasteful, but it's not the bug we are looking for.

Thanks,
Florian