On Wed, Jul 15, 2020 at 11:10:47AM -0400, Mathieu Desnoyers wrote:
> - On Jul 15, 2020, at 8:33 AM, Christian Brauner
> christian.brau...@ubuntu.com wrote:
> [...]
> >
> > So here's a very free-wheeling draft of roughly what I had in mind. Not
> > even compile-tested just to illustrate what
- On Jul 15, 2020, at 10:58 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> - On Jul 15, 2020, at 9:42 AM, Florian Weimer fwei...@redhat.com wrote:
>>> * Mathieu Desnoyers:
>>>
>> [...]
How would this allow early-rseq-adopter libraries to interact with
- On Jul 15, 2020, at 8:33 AM, Christian Brauner
christian.brau...@ubuntu.com wrote:
[...]
>
> So here's a very free-wheeling draft of roughly what I had in mind. Not
> even compile-tested just to illustrate what I'd change and sorry if that
> code will make you sob in your hands:
>
[...]
>
* Mathieu Desnoyers:
> - On Jul 15, 2020, at 9:42 AM, Florian Weimer fwei...@redhat.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
>>
- On Jul 15, 2020, at 9:42 AM, Florian Weimer fwei...@redhat.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
- On Jul 14, 2020, at 10:34 PM, Chris Kennelly ckenne...@google.com wrote:
> On Tue, Jul 14, 2020 at 2:33 PM Peter Oskolkov wrote:
>>
>> On Tue, Jul 14, 2020 at 10:43 AM Mathieu Desnoyers
>> wrote:
>> >
>> > - On Jul 14, 2020, at 1:24 PM, Peter Oskolkov p...@posk.io wrote:
>> >
>> > >
- On Jul 15, 2020, at 2:31 AM, Florian Weimer f...@deneb.enyo.de wrote:
> * Chris Kennelly:
>
>> When glibc provides registration, is the anticipated use case that a
>> library would unregister and reregister each thread to "upgrade" it to
>> the most modern version of interface it knows
- On Jul 15, 2020, at 9:55 AM, Christian Brauner
christian.brau...@ubuntu.com wrote:
> On Wed, Jul 15, 2020 at 03:42:11PM +0200, Florian Weimer wrote:
>> * Mathieu Desnoyers:
>>
>> > So indeed it could be done today without upgrading the toolchains by
>> > writing custom assembler for each
On Wed, Jul 15, 2020 at 03:42:11PM +0200, Florian Weimer wrote:
> * Mathieu Desnoyers:
>
> > So indeed it could be done today without upgrading the toolchains by
> > writing custom assembler for each architecture to get the thread's
> > struct rseq. AFAIU the ABI to access the thread pointer is
* Mathieu Desnoyers:
> So indeed it could be done today without upgrading the toolchains by
> writing custom assembler for each architecture to get the thread's
> struct rseq. AFAIU the ABI to access the thread pointer is fixed for
> each architecture, right ?
Yes, determining the thread pointer
- On Jul 15, 2020, at 9:22 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> Practically speaking, I suspect this would mean postponing availability of
>> rseq for widely deployed applications for a few more years ?
>
> There is no rseq support in GCC today, so you
* Mathieu Desnoyers:
> Practically speaking, I suspect this would mean postponing availability of
> rseq for widely deployed applications for a few more years ?
There is no rseq support in GCC today, so you have to write assembler
code anyway.
Thanks,
Florian
- On Jul 14, 2020, at 5:30 PM, carlos car...@redhat.com wrote:
> On 7/14/20 9:19 AM, Mathieu Desnoyers wrote:
>> Is there an arch-agnostic way to get the thread pointer from user-space code
>> ?
>> That
>> would be needed by all rseq critical section implementations.
>
> Yes, and no. We
On Wed, Jul 15, 2020 at 01:38:51PM +0200, Christian Brauner wrote:
> On Mon, Jul 13, 2020 at 11:03:46PM -0400, Mathieu Desnoyers wrote:
> > Add a __rseq_abi.flags "RSEQ_TLS_FLAG_SIZE", which indicates support for
> > extending struct rseq. This adds two new fields to struct rseq:
> > user_size and
On Mon, Jul 13, 2020 at 11:03:46PM -0400, Mathieu Desnoyers wrote:
> Add a __rseq_abi.flags "RSEQ_TLS_FLAG_SIZE", which indicates support for
> extending struct rseq. This adds two new fields to struct rseq:
> user_size and kernel_size.
>
> The user_size field allows the size of the __rseq_abi
On Wed, Jul 15, 2020 at 08:31:05AM +0200, Florian Weimer wrote:
> * Chris Kennelly:
>
> > When glibc provides registration, is the anticipated use case that a
> > library would unregister and reregister each thread to "upgrade" it to
> > the most modern version of interface it knows about
* Chris Kennelly:
> When glibc provides registration, is the anticipated use case that a
> library would unregister and reregister each thread to "upgrade" it to
> the most modern version of interface it knows about provided by the
> kernel?
Absolutely not, that is likely to break other
On Tue, Jul 14, 2020 at 2:33 PM Peter Oskolkov wrote:
>
> On Tue, Jul 14, 2020 at 10:43 AM Mathieu Desnoyers
> wrote:
> >
> > - On Jul 14, 2020, at 1:24 PM, Peter Oskolkov p...@posk.io wrote:
> >
> > > At Google, we actually extended struct rseq (I will post the patches
> > > here once they
On 7/14/20 9:19 AM, Mathieu Desnoyers wrote:
> Is there an arch-agnostic way to get the thread pointer from user-space code
> ? That
> would be needed by all rseq critical section implementations.
Yes, and no. We have void *__builtin_thread_pointer (void), but
few architectures implement the
On Tue, Jul 14, 2020 at 10:43 AM Mathieu Desnoyers
wrote:
>
> - On Jul 14, 2020, at 1:24 PM, Peter Oskolkov p...@posk.io wrote:
>
> > At Google, we actually extended struct rseq (I will post the patches
> > here once they are fully deployed and we have specific
> > benefits/improvements to
- On Jul 14, 2020, at 1:24 PM, Peter Oskolkov p...@posk.io wrote:
> At Google, we actually extended struct rseq (I will post the patches
> here once they are fully deployed and we have specific
> benefits/improvements to report). We did this by adding several fields
> below __u32 flags (the
At Google, we actually extended struct rseq (I will post the patches
here once they are fully deployed and we have specific
benefits/improvements to report). We did this by adding several fields
below __u32 flags (the last field currently), and correspondingly
increasing rseq_len in rseq()
- On Jul 14, 2020, at 9:00 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>>> How are extensions going to affect the definition of struct rseq,
>>> including its alignment?
>>
>> The alignment will never decrease. If the structure becomes large enough
>> its alignment
* Mathieu Desnoyers:
>> How are extensions going to affect the definition of struct rseq,
>> including its alignment?
>
> The alignment will never decrease. If the structure becomes large enough
> its alignment could theoretically increase. Would that be an issue ?
Telling the compiler that
- On Jul 14, 2020, at 5:58 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> +/*
>> + * Very last field of the structure, to calculate size excluding padding
>> + * with offsetof().
>> + */
>> +char end[];
>> } __attribute__((aligned(4 *
* Mathieu Desnoyers:
> + /*
> + * Very last field of the structure, to calculate size excluding padding
> + * with offsetof().
> + */
> + char end[];
> } __attribute__((aligned(4 * sizeof(__u64;
This makes the header incompatible with standard C++.
How are extensions
26 matches
Mail list logo
