Re: [PATCH 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v10)
flat view
From: Florian Weimer <hidden>
Date: 2019-05-31 08:06:33
Also in:
lkml
* Mathieu Desnoyers:
I found that it's because touching a __thread variable from ld-linux-x86-64.so.2 ends up setting the DF_STATIC_TLS flag for that .so, which is really not expected. Even if I tweak the assert to make it more lenient there, touching the __thread variable ends up triggering a SIGFPE.
Sorry, I got distracted at this critical juncture. Yes, I forgot that there isn't TLS support in the dynamic loader today.
So rather than touching the TLS from ld-linux-x86-64.so.2, I've rather experimented with moving the rseq initialization for both SHARED and !SHARED cases to a library constructor within libc.so. Are you aware of any downside to this approach ?
The information whether the kernel supports rseq would not be available to IFUNC resolvers. And in some cases, ELF constructors for application libraries could run before the libc.so.6 constructor, so applications would see a transition from lack of kernel support to kernel support.
quoted hunk
+static +__attribute__ ((constructor)) +void __rseq_libc_init (void) +{ + rseq_init (); + /* Register rseq ABI to the kernel. */ + (void) rseq_register_current_thread (); +}
I think the call to rseq_init (and the __rseq_handled variable) should still be part of the dynamic loader. Otherwise there could be confusion about whether glibc handles the registration (due the constructor ordering issue). Thanks, Florian