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: Andrew Hunter <ahh at google dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- 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 09:49:42 -0800
- 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> <20140103074522 dot GT24286 at brightrain dot aerifal dot cx>
On Thu, Jan 2, 2014 at 11:45 PM, Rich Felker <dalias@aerifal.cx> wrote:
> 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
Oh yeah, duh. So it's not just a terrible idea, it also just doesn't work.
In practice, I *believe* this exclusively happens in the case I
detailed far upthread (where one object makes a reference to an extern
TLS variable as init-exec) which is fairly contrived and I'm not too
worried about the fact that it's unreliable. And I don't believe this
patch actually changes the behavior there, anyway.