This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Async signal safe TLS accesses


On Wed, Oct 02, 2013 at 03:50:09PM -0700, Andrew Hunter wrote:
> On Wed, Oct 2, 2013 at 3:36 PM, Rich Felker <dalias@aerifal.cx> wrote:
> > The idea that dlopen has to poke at all existing threads is wrong.
> > That's the complex, error-prone way to implement safe TLS allocation.
> > The other way is to simply allocate sufficient space (including space
> > for enlarged DTVs) for the currently existing number of threads, but
> > wait to give it to them until they call __tls_get_addr.
> >
> 
> Note that as I understand the spec, this just doesn't work for
> initial-exec TLS in dlopen'd modules.  By the time dlopen returns, the
> relevant relocation needs to contain an offset that has the valid
> initial TLS image in all extant threads. (Remember that with
> initial-exec TLS we may never get a call to tls_get_addr with which to
> lazily initialize the region.)  This means dlopen must iterate all
> threads and fill in the correct offset with the image (as it does,
> already, with or without my patch.)
> 
> One can argue that maybe dlopen should not support initial-exec but
> that ship has, in fact, sailed.

Since when does dlopen support initial-exec? I am not aware of any
such support, and it certainly can't work in general since the needed
address range might not even be available.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]