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

----- On Jan 14, 2019, at 10:55 AM, Florian Weimer fweimer@redhat.com wrote:

* Mathieu Desnoyers:

quoted

Therefore, both symbols will end up in
sysdeps/unix/sysv/linux/Versions.

I'm not sure what you mean by that.  The physical location in the
directory tree has little effect on which shared object the symbol is
placed in; that will need other changes.

I'm currently moving the symbol definitions to csu/rseq-sym.c. On Linux,
its content is overridden by a new sysdeps/unix/sysv/linux/rseq-sym.c
which contains both __rseq_abi and __rseq_refcount symbols. On other
platforms, it is a stub file.

quoted

quoted

By the way, you could avoid the need for unregistration if you allocated
the rseq areas persistently, index by TID.  They are quite small, so
with the typical PID range, maybe the wasted memory due to changing TIDs
would be acceptable?

Would we be able to access those __rseq_abi as normal TLS IE model
variables ?  The overhead of indexing an array matters for a
fast-path.

No, that wouldn't be possible in this case.  You would need another
indirection.

Thanks for the clarification!

Mathieu


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