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: Torvald Riegel <triegel at redhat dot com>
- To: Alexandre Oliva <aoliva 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: Tue, 09 Jun 2015 14:05:53 +0200
- 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> <oregllzk87 dot fsf at livre dot home>
On Mon, 2015-06-08 at 23:30 -0300, Alexandre Oliva wrote:
> 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?
Your comment, that you claimed was crystal-clear, seems inconsistent
with what you described elsewhere. That's the reason.
> > 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.
>
I can't follow you; I don't see how it addresses my comment. But given
that you'll stop working on this patch anywhere and have handed it off
to Siddhesh, I'll discuss with Siddhesh.