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: Kostya Serebryany <kcc at google dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Paul Pluzhnikov <ppluzhnikov at google dot com>, Andrew Hunter <ahh at google dot com>, "Carlos O'Donell" <carlos at redhat 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: Sat, 25 Jan 2014 00:52:20 +0400
- Subject: Re: glibc 2.19 - asyn-signal safe TLS and ASan.
- Authentication-results: sourceware.org; auth=none
- References: <52D0BCED dot 3000109 at redhat dot com> <52DDBF0E dot 8010501 at redhat dot com> <CAN=P9piS3Xczq2AKrzh4rsK9JxiHtJXawcQs9_+xsYXxrbLQWQ at mail dot gmail dot com> <CADroS=6vODmWCdBsynOf7oM9uVDymwdxrSDFbmD6kT5P9gbBRw at mail dot gmail dot com> <CAN=P9pgAYNZBUBbg2_SiwCjB5vXJ6ZXTNS=yoZWSvS3JoX1bGQ at mail dot gmail dot com> <52E2A098 dot 7060908 at google dot com> <Pine dot LNX dot 4 dot 64 dot 1401241747120 dot 9799 at digraph dot polyomino dot org dot uk>
[text-only]
On Fri, Jan 24, 2014 at 9:53 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Fri, 24 Jan 2014, Paul Pluzhnikov wrote:
>
>> I *think* exporting these symbols for 2.19 is the right thing to do.
>
> I don't think such symbols are a good idea for the public interface (as
Could you think of some other way to un-break LeakSanitizer in the
2.19 time frame?
(I suppose that https://sourceware.org/bugzilla/show_bug.cgi?id=16291
can not be properly implemented for 2.19).
I am sure we will find some even uglier hack to support both 2.19 and
pre-2.19, but that will be most unfortunate...
Thanks!
--kcc
> opposed to GLIBC_PRIVATE) - and in any case, symbols should not be added
> to the public interface during release freeze, unless only for an
> architecture for which you are doing the release testing, because adding
> public symbols means updating all the ABI baselines and retesting in all
> relevant configurations.
>
> Specifically, I think of the present solution as an interim solution,
> until someone implements TLS in a way that does the allocation at
> pthread_create / dlopen time and avoids the possibility of allocation
> failure where an error cannot be returned. And it's not obvious that such
> non-lazy allocation would need signal-safe allocators at all - meaning
> that glibc built for new architectures, not needing compatibility for any
> old binaries relying on overcommit for TLS variables, could then avoid
> including those allocators (presuming we keep them at all to make
> allocation for existing binaries signal-safe).
>
> Exporting symbols at GLIBC_PRIVATE is not a good solution for externally
> maintained projects because those shouldn't be using GLIBC_PRIVATE symbols
> at all.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com