This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: TLS, 2015 edition
- From: Stan Shebs <stanshebs at google dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Tue, 31 Mar 2015 11:33:06 -0500
- Subject: Re: TLS, 2015 edition
- Authentication-results: sourceware.org; auth=none
- References: <CA+5-Q5K7M3oJ-vvRP24GiCEHqnohWgqPkc7_6K9CLzc6a_MTcA at mail dot gmail dot com> <551A763A dot 5070909 at arm dot com> <CA+5-Q5K3fmH0AM=qa6uCT0zPvF+XLLopzpk0MzWCSK5Bzn9CNw at mail dot gmail dot com> <551AC46C dot 8060901 at arm dot com>
On Tue, Mar 31, 2015 at 10:59 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
>
> On 31/03/15 16:55, Stan Shebs wrote:
>> On Tue, Mar 31, 2015 at 5:26 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>>>
>>>
>>> On 30/03/15 23:50, Stan Shebs wrote:
>>>> Through a series of unfortunate events (starting with an infinite loop
>>>> in an obscure Java test) I seem to have inherited the async-safe TLS
>>>> problem.
>>>>
>>>
>>> i don't know about this bug, but i assume this is a lazy
>>> binding issue
>>>
>>> in that case linking with '-z now' should solve the problem
>>> (..assuming glibc does the dynamic tls allocation at load
>>> time then and at thread creation time)
>>
>> We've identified two mistaken bits in the Google-local patch so far,
>> and there may be more. It's just wasteful to be doing patch-on-patch
>> if we could have a version upstream and properly maintained instead.
>>
>
> can you give more details?
It was getting quite a bit of libc-alpha traffic in late 2013 and
early 2014, and there is a wiki page:
https://sourceware.org/glibc/wiki/TLSandSignals
The following posting is the leader for one of several versions that
Andrew Hunter posted:
https://sourceware.org/ml/libc-alpha/2013-12/msg00212.html
The Google-local patch is a descendant of that code. (In theory Google
ought to have a git branch, but I only see ones for Roland?)
Stan