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

[Mathieu Desnoyers]

----- On Mar 22, 2019, at 1:34 PM, Carlos O'Donell codonell@redhat.com wrote:

> On 2/12/19 2:42 PM, Mathieu Desnoyers wrote:
>> 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 have no objection to RSEQ_SIG being a signature that each architecture uses.
> 
> Can you summarize the previous discussions here?

The culprit is whether we provide an architecture-agnostic "generic" value
for RSEQ_SIG for architectures that do not define a specific RSEQ_SIG, or
leave RSEQ_SIG undefined for architectures that do not define it yet.

Considering that RSEQ_SIG ends up being a 32-bit value that maps to actual
architecture code compiled into applications and libraries, it's
understandable that it needs to be defined for each architecture specifically.
For instance, generating invalid instructions may have ill effects on tools like
objdump, and may also have impact on the CPU speculative execution efficiency
in some cases.

There has been ideas floating around about having a "generic" value for
RSEQ_SIG that would apply to all architectures that do not override it.
However, if we have this, it makes it impossible for those architectures
to ever define a different value if they ever choose so, because that value
ends up being an ABI that is built into applications and libraries including
the glibc rseq header. Changing that value would break applications.

So I favor _not_ defining any generic RSEQ_SIG, and adding per-architecture
RSEQ_SIG define gradually. Therefore, user-space can #ifdef on whether
RSEQ_SIG is defined or not after including the glibc rseq header.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com