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: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Paul Pluzhnikov <ppluzhnikov at google dot com>
- Cc: Kostya Serebryany <kcc 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: Fri, 24 Jan 2014 17:53:20 +0000
- 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>
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
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