This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Async signal safe TLS accesses
- From: Rich Felker <dalias at aerifal dot cx>
- To: Andrew Hunter <ahh at google dot com>
- Cc: Paul Pluzhnikov <ppluzhnikov at google dot com>, GNU C Library <libc-alpha at sourceware dot org>, allan at archlinux dot org, Carlos O'Donell <carlos at redhat dot com>
- Date: Fri, 3 Jan 2014 02:45:22 -0500
- Subject: Re: [PATCH] Async signal safe TLS accesses
- Authentication-results: sourceware.org; auth=none
- References: <52C4DC54 dot 4000109 at redhat dot com> <1388689454-1854-1-git-send-email-ahh at google dot com> <CALoOobPio5625ws7dSWepgQbKmqHifvbU3tKWtKFS-tz_zihdQ at mail dot gmail dot com> <CADroS=7BBPbJ5bAUUy5VUWHX+gCrRmrEk17qO-s9zkdVNeFbxA at mail dot gmail dot com>
On Thu, Jan 02, 2014 at 11:31:42PM -0800, Andrew Hunter wrote:
> On Thu, Jan 2, 2014 at 6:48 PM, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:
> > This one looks like a possible bug to me:
> > it will always error if map->l_tls_offset == FORCED_DYNAMIC_TLS_OFFSET.
> >
>
> I believe this is WAI -- if I remember correctly you're quoting the
> snippet invoked when we need to fulfill a TLS relocation while loading
> code that assumes init-exec model for some TLS variable X. If X's
> map->l_tls_offset = FORCED_DYNAMIC, that means that X was already
> accessed from at least one thread, which did so in dynamic model (and
> malloced an arena to hold the section). This means that thread can't
> use a static TLS offset; we can't fulfill that relocation; ERROR.
> (Well, we could sighandler over to each thread and move their dynamic
> area to the static TLS section, but...no.)
No, you can't; you cannot prove that the application did not already
save the address of a thread-local object for later usage. If it did,
moving the object to a different address would be illegal.
Rich