[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