This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.19 - asyn-signal safe TLS and ASan.
- From: Rich Felker <dalias at aerifal dot cx>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Kostya Serebryany <kcc at google dot com>, Paul Pluzhnikov <ppluzhnikov at google dot com>, OndÅej BÃlka <neleai at seznam dot cz>, "Joseph S. Myers" <joseph at codesourcery dot com>, Andrew Hunter <ahh at google dot com>, GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, address-sanitizer at googlegroups dot com
- Date: Thu, 30 Jan 2014 11:54:45 -0500
- Subject: Re: glibc 2.19 - asyn-signal safe TLS and ASan.
- Authentication-results: sourceware.org; auth=none
- References: <20140125010534 dot GA14587 at domone dot podge> <CALoOobNc8mNUHLhry-hcqT6fx9m=HukMw1Sy41Q+uhRDBznbSw at mail dot gmail dot com> <20140125030232 dot GA14213 at domone dot podge> <CAN=P9pgiMRxxYK16ZaVje1AQbC+fQ=QUDhsdww5-8RWaiJswoA at mail dot gmail dot com> <CALoOobMdh7wOHPPB6vTTLb0wXeO-yGA75MvHohrqGPAY-CcC2g at mail dot gmail dot com> <CAN=P9pjAW6bMip+hsE6mDUA2MFfdC7fNCvrgNyhG2GRQGJJNCw at mail dot gmail dot com> <CAN=P9pj+EVcrUwxa+70eEVY-_sqaU1d6s8HjsP4BkY8N+G-JVg at mail dot gmail dot com> <52E9E1E7 dot 3090505 at redhat dot com> <CAN=P9pgyfA6hTC2LcQEpALo62g8+wN0Ne-eJsMnZ7iR1m9rzOg at mail dot gmail dot com> <52E9E7CF dot 9060706 at redhat dot com>
On Thu, Jan 30, 2014 at 12:49:03AM -0500, Carlos O'Donell wrote:
> 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.
Or a signal handler happened to interrupt __tls_get_addr and something
from the signal handler caused __libc_memalign to get called. Is this
case handled?
> > 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.
I would say making assumptions about the format of the header is
pretty ugly and might even break in the future, especially if the
intent is to eventually allow overriding the AS-safe malloc
implementation...
Rich