Hi Chris,
You will probably want to have a look at the userspace rseq ABI exposed by glibc 2.35 to ensure
tcmalloc becomes compatible with it.
If it helps, you can have a look at how I modified librseq to play nicely with glibc 2.35:
https://git.kernel.org/pub/scm/libs/librseq/librseq.git/
Most relevant bits:
https://git.kernel.org/pub/scm/libs/librseq/librseq.git/tree/src/rseq.c#n108
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
* Mathieu Desnoyers:
> 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.
I'm going to post a patch. It's fairly small.
Thanks,
Florian
On 2/2/22 10:01, Florian Weimer via Libc-alpha wrote:
> * Mathieu Desnoyers:
>
>> 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.
>
> I'm going to post a patch. It's fairly small.
I'll review this as glibc release manager for glibc 2.35.
We'll get this right before I cut the release.
--
Cheers,
Carlos.