This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PR18457] Don't require rtld lock to compute DTV addr for static TLS
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>, libc-alpha at sourceware dot org
- Date: Mon, 08 Jun 2015 23:30:48 -0300
- Subject: Re: [PR18457] Don't require rtld lock to compute DTV addr for static TLS
- Authentication-results: sourceware.org; auth=none
- References: <orvbf5ffyt dot fsf at livre dot home> <20150603152448 dot GC32684 at spoyarek dot pnq dot redhat dot com> <5570819F dot 3070902 at redhat dot com> <orr3pqdbqm dot fsf at livre dot home> <5571E6E9 dot 50604 at redhat dot com> <orr3pqarri dot fsf at livre dot home> <1433710090 dot 21461 dot 418 dot camel at triegel dot csb>
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