[PATCH v10 2/4] Add rseq extensible ABI support
Florian Weimer
fweimer@redhat.com
Mon Jul 8 07:05:57 GMT 2024
* Michael Jeanson:
>>> And what would you suggest as a way forward? Adding ifdefs in the
>>> current function or moving this code to some other location?
>> I would put a header file into sysdeps/generic/dl-extra_tls.h with
>> the
>> following functions:
>> _dl_extra_tls_get_size () returns the size of the extra TLS
>> allocation.
>> _dl_extra_tls_get_align () returns its alignment.
>> _dl_extra_tls_set_offset () sets the offset from the thread pointer.
>> The default implementations in sysdeps/generic/dl-extra_tls.h should
>> be
>> inline and do nothing. In sysdeps/unix/sysv/linux/dl-extra_tls.h, there
>> could be the real implementation (probably inline as well). It would
>> use the _rseq_* variables.
>
> Would the goal be to try to remove all rseq related terminology from
> 'csu/libc-tls.c' and 'elf/dl-tls.c' and replace it with the generic
> concept of 'extra_tls'?
Yes, that's my suggestion.
> Thanks for this, I implemented most of your recommendations and I now
> have a patchset building on both Linux and Hurd. It still needs some
> cleanup but I don't think there is any rush since we are now targeting
> 2.41.
I posted a variant of the symbol change recently for 2.40, let's hope it
goes in.
>>>> Why is it necessary to duplicate these variables? Is not a duplicate
>>>> and I assume it looks like the it's now used for TLS allocation on
>>>> new threads, which means it's needed. Is it necessary to add it to
>>>> GLRO?
>>>
>>> GLRO(dl_tls_rseq_feature_size) / GLRO(dl_tls_rseq_align): I followed
>>> the same pattern as the other AUXV variables in
>>> "sysdeps/unix/sysv/linux/dl-parse_auxv.h"
>>>
>>> _dl_tls_rseq_alloc_size: is used to keep track of the size of the
>>> allocated rseq tls block which we need to zero initialize on thread
>>> creation and will differ from '__rseq_size' in the case of a failed
>>> registration.
>> Ahh. This one will actually have to remain in GLRO because we'll
>> need
>> it in libc during thread creation.
>
> Ack.
We can use __rseq_size from libc and increase it to 32 if it less than
32 (see the patch I posted).
Thanks,
Florian
More information about the Libc-alpha
mailing list