[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAEE+ybn_Cp1-T=2uB7xJqU2gEU-PxzsaV5jqCOupNp2cx_bK-Q@mail.gmail.com>
Date: Tue, 1 Feb 2022 15:33:15 -0500
From: Chris Kennelly <ckennelly@...gle.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Paul Turner <pjt@...gle.com>, Peter Oskolkov <posk@...k.io>,
Florian Weimer <fweimer@...hat.com>,
libc-alpha <libc-alpha@...rceware.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: Aligning tcmalloc with glibc 2.35 rseq ABI
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.
I saw https://lkml.org/lkml/2022/1/24/859 mention using %gs, but it
also mentions consulting "rseq_offset" in the address calculation. Is
rseq_offset something I can resolve to a constant or would I need to
access a global for it, or does glibc take care of initializing %gs to
the address of the structure registered with the kernel (for the
current thread)?
Thanks,
Chris
On Tue, Feb 1, 2022 at 9:58 AM Mathieu Desnoyers
<mathieu.desnoyers@...icios.com> wrote:
>
> 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
Powered by blists - more mailing lists