Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation

* Rich Felker:

On Fri, Nov 23, 2018 at 06:39:04PM +0100, Florian Weimer wrote:

quoted

* Rich Felker:

quoted

On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:

quoted

There has been presumptions about signals being blocked when the thread
exits throughout this email thread. Out of curiosity, what code is
responsible for disabling signals in this situation ? Related to this,
is it valid to access a IE model TLS variable from a signal handler at
_any_ point where the signal handler nests over thread's execution ?
This includes early start and just before invoking the exit system call.

It should be valid to access *any* TLS object like this, but the
standards don't cover it well.

C++ makes it undefined:

  <http://eel.is/c++draft/support.signal#def:evaluation,signal-safe>

C also leaves access to pretty much anything from a signal handler
undefined, but that makes signals basically useless.

Access to atomic variables of thread storage duration is defined,
though.

Thanks,
Florian