This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: glibc 2.19 - asyn-signal safe TLS and ASan.


On 01/30/2014 12:33 AM, Kostya Serebryany wrote:
> On Thu, Jan 30, 2014 at 9:23 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>>
>> On 01/29/2014 04:48 AM, Kostya Serebryany wrote:
>>> [text only]
>>>
>>>> Indeed so, thanks!
>>>> So, exporting __signal_safe_memalign&co will allow us to extend the
>>>> existing hack to 2.19.
>>>> If this simple change can not be done for 2.19, can *anything* be done at all?
>>>> (Long term we'd still prefer something less hackish)
>>>
>>> FTR, I've implemented an even-uglier-then-before hack that deals with
>>> dynamic TLS in both <=2.18 and 2.19.
>>> So, we will survive the 2.19 release.
>>> But I would appreciate if we can resolve
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=16291
>>> before the next one (2.20).
>>
>> Can you please describe the hack?
> 
> 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.

Not terrible at all, quite elegant actually.

Thanks.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]