[PR18457] Don't require rtld lock to compute DTV addr for static TLS

Alexandre Oliva aoliva@redhat.com
Tue Jun 9 03:11:00 GMT 2015


On Jun  7, 2015, Torvald Riegel <triegel@redhat.com> wrote:

> That sounds like it is not just about reaching consensus on the final
> value of l_tls_offset:  For example, you mention initialization in
> there,

Yeah, we've already covered the relocation in the tls initialization
block, performed by the dynamic loader.  Why do we have to go in
circles?

> Also, it sounds as if any thread concurrent with the dlopen could only
> actually create a concurrent access if dlopen has the lock already --
> but that doesn't seem to be a requirement based on the "spin"
> example/analogy you gave.

There are two roles dlopen plays here:

1. loading the module that defines the TLS variable

2. applying TLS replications to modules that reference the TLS variable

It might turn out that 1. and 2. are performed under a single rtld lock
taking, and a subsequent dlopen could bring in additional references to
TLS variables.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer



More information about the Libc-alpha mailing list