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

----- On Jan 14, 2019, at 2:37 PM, Florian Weimer fweimer@redhat.com wrote:

* Mathieu Desnoyers:

quoted

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

quoted

* 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.

You don't need a stub file if you use the “ifeq ($(subdir),csu)”
construct.

OK

The other question is whether this belongs into the csu subdirectory.
Since TLS is not available in ld.so, the initialization would have to
happen rather late, after relocation, but before ELF constructors are
run.

(A side effect is that the rseq area would not be usable from IFUNC
resolvers.)

Do you have a specific directory location in mind where we should put
the built object ? e.g. "ifeq ($(subdir),posix)" or
"ifeq ($(subdir),misc)" ?

Moreover, from where should we call the rseq initialization ? I'm having
trouble with invalid system calls parameters if I place it in
LIBC_START_MAIN() just before or after the call to __pthread_initialize_minimal.
I get what appears to be invalid parameters to sys_rseq, possibly due to
stack corruption (?). I'm investigating at the moment. But if you prefer
we call the rseq init from elsewhere, please let me know.

Thanks,

Mathieu

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