Re: glibc 2.19 status?

["Carlos O'Donell" <carlos at redhat dot com>]

On 01/30/2014 12:10 AM, Carlos O'Donell wrote:
> On 01/28/2014 03:56 PM, Roland McGrath wrote:
>>> 1) Is there anything currently blocking a release?
>>>
>>> I have seen a number of posts about the TLS changes, but an not sure
>>> from the conversations of whether this is considered a blocker.  Is that
>>> needing dealt with?  If so, what time-frame are we looking at?
>>
>> I think the TLS situation should be considered a blocker.
>> But I have yet to follow up on people's replies about the subject.
>> I'll try to do that soon.
> 
> I agree. At the very least we need a day or two (this weekend) to
> think about what to provide for ASAN to use to find TLS and stack
> extends easily. I'll do the thinking. If we give up on it we give
> up on it, but we shouldn't do so without trying.

OK, so Konstantin says they have a hack in place to fix ASAN.

Namely:
~~~
> intercept __tls_get_addr and __libc_memalign.
> if __libc_memalign is called while we are inside __tls_get_addr, we
> know we are in <= 2.18 mode and we know what to do.
> if __libc_memalign was not called but the DSO ID passed to
> __tls_get_addr was not seen before by the current thread,
> we know that we are in 2.19 mode and that the TLS block was allocated
> by __signal_safe_memalign, which
> has a header with the actual block size. Ugly, as I said.
~~~

Given the workaround I'd like to defer this discussion until
after the 2.19 release.

We will work to provide an API for this information in 2.20.

Cheers,
Carlos.