Messages in this thread | | | Date | Wed, 12 Jun 2019 10:36:03 -0400 (EDT) | From | Mathieu Desnoyers <> | Subject | Re: [PATCH 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v10) |
| |
----- On Jun 12, 2019, at 4:22 PM, Florian Weimer fweimer@redhat.com wrote:
> * Mathieu Desnoyers: > >>> It's the registration from libc.so which needs some care. In >>> particular, we must not override an existing registration. >> >> OK, so it could check if __rseq_abi.cpu_id is -1, and only >> perform registration if it is the case. Or do you have another >> approach in mind ? > > No, __rseq_abi will not be shared with the outer libc, so the inner libc > will always see -1 there, even if the outer libc has performed > registration. > > libio/vtables.c has some example what you can do: > > /* In case this libc copy is in a non-default namespace, we always > need to accept foreign vtables because there is always a > possibility that FILE * objects are passed across the linking > boundary. */ > { > Dl_info di; > struct link_map *l; > if (!rtld_active () > || (_dl_addr (_IO_vtable_check, &di, &l, NULL) != 0 > && l->l_ns != LM_ID_BASE)) > return; > } > > _IO_vtable_check would have to be replaced with your own function; the > actual function doesn't really matter. > > The rtld_active check covers the static dlopen case, where > rtld_active () is false in the inner libc.
Then out of curiosity, would it also work if I check for
if (!__libc_multiple_libcs)
in LIBC_START_MAIN ?
Thanks,
Mathieu
-- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
| |