On Fri, Jan 24, 2014 at 9:53 PM, Joseph S. Myers <[email protected]>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 > [email protected] > -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
