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

[Carlos O'Donell <carlos at redhat dot com>]

On 02/20/2018 12:24 PM, Konstantin Serebryany wrote:
> Hi,
> 
> Users are reporting that the fresh glibc breaks AddressSanitizer (asan)
> and probably other sanitizers too.
> 
> https://bugs.llvm.org/show_bug.cgi?id=36065
> https://bugs.llvm.org/show_bug.cgi?id=36326
> https://github.com/google/sanitizers/issues/914
> 
> The problem seems to be in the new way the dynamic TLS is allocated.
> The current implementation in asan is hackish and a few years back
> we discussed a better one
> (https://sourceware.org/glibc/wiki/ThreadPropertiesAPI)
> but the discussion has stalled.
> 
> Can this be addressed in 2.25? At lest the dtls side?

As others have pointed out, glibc 2.25 has a frozen API and ABI at this
point, no new API will be added to 2.25.

As an upstream maintainer I strongly suggest ensuring that both gcc and
llvm have sufficient regression tests that the issues appear with newer
glibc, this way we can know, when bootstrapping the toolchain, that something
is wrong e.g. glibc/scripts/build-many-glibcs.py does this for us today.

We don't intend to break things, we are simply changing things which no user
should ever expect to be stable, and doing so because we are fixing real
bugs users report, and not just being mean :-)

> Even if we put another set of hacks into the sanitizers to support 2.25,
> the new glibc will break things for those who use older GCC or LLVM versions.

Correct. You may need a condition for every version of glibc which you support
which has a different layout that impacts your requirements. You have no
guarantees from us that these structures will not change.

This is analogous to kernel debug tooling which almost always needs to know
exactly which kernel version you have to parse the kernel internals data
directly.

Someone, yourself, or others, need to move forward a consensus discussion,
with a design document for the new API, and get agreement on what it would
look like, and how it would be implemented.

Those most interested in the API need to move that discussion forward.

In summary:

* Try hard to ensure sufficient regression tests are available in gcc and
  llvm that things are seen early. It sounds like from H.J.s comments that
  gcc *does not* have such regression tests? These would really help us.

* Keep moving on a consensus discussion for an API that solves your needs,
  starting with the design of that API.

-- 
Cheers,
Carlos.