Re: glibc 2.25 seems to have broken AddressSaniitzer Inbox x glibc x sanitizer x

[Florian Weimer <fweimer at redhat dot com>]

On 05/09/2018 12:42 AM, Konstantin Serebryany wrote:
> This is not really what I am asking for.
>
> Our current situation is that asan (ab)uses undocumented and unsupported
> features of
> glibc that glibc periodically changes, and has the full right to do so.
>
> What I am asking for is to have a set of documented and supported features
> that will support asan
> and that will be tested as part of the main glibc test suite.
> (https://sourceware.org/glibc/wiki/ThreadPropertiesAPI  is my old attempt,
> but it didn't get attention)

I think these abstractions are not really helpful because they imply a 
specific implementation strategy for (dynamic) TLS which may or may not 
apply in the future.

We already have a documented interface for TLS (the ABI).  I think there 
is more value in making the dynamic linker replaceable as a whole, 
instead of coming up with hooks that may or may not appropriate a couple 
years down the road.  With “replaceable” I mean that there is a stable 
ABI between libc.so.6 and the dynamic linker, so that you can use 
different implementation.

I don't think anyone has code for this, so it's all pie-in-the-sky.  It 
is not very likely that I will be able to work on this in the near future.

In the meantime, I agree with Joseph: We should paper over issues with 
the current approach with more testing.

Thanks,
Florian