Messages in this thread | | | Date | Wed, 2 Feb 2022 08:08:55 -0500 (EST) | From | Mathieu Desnoyers <> | Subject | Re: Aligning tcmalloc with glibc 2.35 rseq ABI |
| |
----- On Feb 2, 2022, at 6:36 AM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote:
> ----- On Feb 2, 2022, at 3:41 AM, Florian Weimer fweimer@redhat.com wrote: > >> * Florian Weimer: >> >>> * Chris Kennelly: >>> >>>> Thanks for the heads up. >>>> >>>> I did have a question about whether the new protocol would introduce >>>> an extra memory reference while initializing a critical section. >>>> >>>> * With initial-exec TLS, I can directly reference __rseq_abi. >>>> * With the new ABI, I might need to ask glibc for the address of the >>>> registered rseq structure in its thread data. >>> >>> You can write __rseq_offset to a static/hidden variable in an ELF >>> constructor, and then use pretty much the same assembler sequences as >>> for initial-exec TLS on most architectures. >> >> And now I'm kind of worried that we should be using ptrdiff_t for >> __rseq_offset because that's what the initial-exec relocations use. 8-/ > > I suspect the underlying question here is: how likely is it that a libc > requires an offset of more than 2GB either way from the thread pointer > to allocate its rseq thread area on a 64-bit architecture ?
More to the point: is ptrdiff_t the correct type here ? I think so. Do we want to revert the ABI and wait another 6 months before we bring back rseq into glibc just for this ? I'm not sure this limitation justifies it.
So if there is a quick way to fix that before the official 2.35 release, I'm all for it, otherwise I cannot say that __rseq_offset being an "int" rather than a "ptrdiff_t" will make much real-life difference (unless I'm proven wrong). But we will be stuck with this quirk forever.
Thanks,
Mathieu
-- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
| |