[PATCH] elf: Support recursive use of dynamic TLS in interposed malloc

Szabolcs Nagy szabolcs.nagy@arm.com
Tue Jun 25 13:48:36 GMT 2024


The 06/25/2024 14:00, Florian Weimer wrote:
> * Szabolcs Nagy:
> > i wonder if we could do something like ppc tls optimization:
> > special modid value means the GET_ADDR_OFFSET is already
> > the final offset relative to tp (assuming this can work for
> > local dynamic access without DTPOFF reloc). so there is no
> > dtv entry at all for modules with static tls and handle them
> > in asm fast paths.
> 
> I don't think optimizing this is worth it.  We should switch to eager
> TLS allocation, then __tls_get_addr would look like this:
> 
> void *
> __tls_get_addr (GET_ADDR_ARGS)
> {
>   dtv_t *dtv = THREAD_DTV ();
>   return (char *) dtv[GET_ADDR_MODULE] + GET_ADDR_OFFSET;
> }
> 
> With multiple modules sharing one TLS module ID.  I assume that's what
> musl is doing today.

i don't think there is modid sharing in musl, otherwise yes.

at thread exit musl only frees the dtv that was allocated at
thread creation, but if a module is loaded later it will alloc
and install dtv in all threads and this will never be freed.

so each new dlopen may alloc tls_size*nthreads that is leaked.
this may be an issue with frequent dlopen (which is not an
issue in practice for musl because of the nop dlclose).

> 
> I've created a lightly tested variant of the patch that uses TLS instead
> of a global variable for the in-malloc state.  I don't think it's an
> improvement (particularly because of the missing compiler barrier before
> THREAD_GETMEM), so I'd like to stick with the first patch.

is it really possible to call the new functions before tp is
initialized?

i think orig is fine as the atomics should be in slow paths.




More information about the Libc-alpha mailing list