This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: TLS, 2015 edition
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Stan Shebs <stanshebs at google dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Tue, 31 Mar 2015 16:59:40 +0100
- 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>
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?
having local patches for such issues does not
sound reasonable