This is the mail archive of the
mailing list for the glibc project.
rseq notes from Cauldron
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: libc-alpha at sourceware dot org
- Cc: Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>
- Date: Mon, 23 Sep 2019 10:45:26 +0200
- Subject: rseq notes from Cauldron
Here are my notes from Cauldron.
We definitely want to eliminate the intermediate states related to
__rseq_handled and __rseq_handled itself. This requires an
early-initialization callback from the dynamic loader to libc. This
is something we (as the libc maintainers) need to provide, and it is
generally useful for other stuff as well (such as setting up
__libc_multiple_libcs correctly). I'm not sure if I can work on this
before October, though.
We need to disable symbols in pthread_create, so that signal handlers
on the new thread cannot observe the lack of rseq registration there.
I think this can be put into the rseq patch.
We need a comment somehwere in NPTL about the reliance of the rseq
area on implicit deregistration. This is currently not a problem
because it lives on the stack (as static TLS), and the stack outlives
the thread. But if we ever change the TCB allocation, additional
steps may be required. It is NOT sufficient to block signals because
the kernel may write to the rseq area even without signals. This
should go into the rseq patch as well.
dlclose needs to reset the cs pointer before unmapping code. I think
this should be part of the rseq patch.
We need a little bit of documentation for the manual, mentioning the
new symbol and the public header. Likewise, this should be part of
Ideally, we should search for RSEQ_SIG in a collection of binaries.
This is probably something I should do (hopefully some time in