[PATCH 0/4] Restartable Sequences support for glibc 2.30

[Carlos O'Donell]

On 3/22/19 1:51 PM, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>> On 3/22/19 1:39 PM, Florian Weimer wrote:
>>> * Mathieu Desnoyers:
>>>
>>>> The only point that still appears to not reach concensus is whether it's
>>>> acceptable to define the RSEQ_SIG code signature for each architecture.
>>>> If I missed other points that failed to reach concensus, please let me
>>>> know!
>>>
>>> I still think the registration mechanism is very problematic and
>>> should be avoided.
>>
>> The *entire* registration mechanism?
> 
> The reference-counting part.  It's going to be of limited use, for a
> few years at most, and we'll have to carry it forward indefinitely.
> I don't think it's worth the complexity.

I can understand Mathieu's position here, he wants to enable all
kinds of users, and wants to write libraries that use rseq today
but which work with future glibc. This is a perfectly reasonable
thing to want. The question we have to ask is the cost.

My suggestion is as follows, tell me what you think:

(a) Add a RSEQ_REGISTER_ALWAYS. The meaning of which is that the
     core C library does unconditional registration/unregistration
     for all threads, and that your application must not call
     rseq with flags 0 (register)/RSEQ_FLAG_UNREGISTER.

(b) In a few years we remove all the ref count code and define
     a __rseq_lib_abi with a register_state that is set to
     a constant value of RSEQ_REGISTER_ALWAYS, and do nothing else.

This way we have a way to backout the ref count process and just
leave a public data symbol as the only part of the ABI.

My idea is that we just need one more RSEQ_REGISTER_* value to
indicate that libc has taken over unconditional registration.

Thoughts?

-- 
Cheers,
Carlos.