[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87k0z4zuxq.fsf@oldenburg2.str.redhat.com>
Date: Wed, 15 Jul 2020 16:58:41 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: carlos <carlos@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
paulmck <paulmck@...ux.ibm.com>,
Boqun Feng <boqun.feng@...il.com>,
"H. Peter Anvin" <hpa@...or.com>, Paul Turner <pjt@...gle.com>,
linux-api <linux-api@...r.kernel.org>,
Christian Brauner <christian.brauner@...ntu.com>
Subject: Re: [RFC PATCH 2/4] rseq: Allow extending struct rseq
* Mathieu Desnoyers:
> ----- On Jul 15, 2020, at 9:42 AM, Florian Weimer fweimer@...hat.com wrote:
>> * Mathieu Desnoyers:
>>
> [...]
>>> How would this allow early-rseq-adopter libraries to interact with
>>> glibc ?
>>
>> Under all extension proposals I've seen so far, early adopters are
>> essentially incompatible with glibc rseq registration. I don't think
>> you can have it both ways.
>
> The basic question I'm not sure about is whether we are allowed to increase
> the size and alignement of __rseq_abi from e.g. glibc 2.32 to glibc 2.33.
With the current mechanism (global TLS data symbol), we can do that
using symbol versioning. That means that we can only do this on a
release boundary, and that it's incompatible with other libraries which
use an interposing unversioned symbol.
Thanks,
Florian
Powered by blists - more mailing lists