This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.25 seems to have broken AddressSaniitzer Inbox x glibc x sanitizer x
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>, Josh Stone <jistone at redhat dot com>
- Date: Thu, 22 Feb 2018 13:55:28 +0000
- Subject: Re: glibc 2.25 seems to have broken AddressSaniitzer Inbox x glibc x sanitizer x
- Authentication-results: sourceware.org; auth=none
- References: <CAGQ9bdyZDj6gs6G3h2gQ2UyWVMHpuYi3SU0zyJKfGDumP3hJTA@mail.gmail.com> <ce91123a-840c-f7d4-4078-7287a4018ab1@redhat.com>
On Wed, 21 Feb 2018, Carlos O'Donell wrote:
> 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.
You also need a bot that runs those tests with current glibc, and ensure
someone is monitoring results and reporting issues within a day or two of
any changes being committed that cause problems. Only detecting problems
after a glibc version with a change has been released is too late for some
fixes.
With build-many-glibcs.py we detect *build* failures with mainline GCC
(including cases where it's e.g. libgcc or libstdc++ that fails to build)
within a day or so. But since the focus there is on testing the build of
glibc and its tests, that doesn't include libraries such as libsanitizer
or libgfortran that aren't needed for building glibc tests - and it
doesn't include any execution testing.
--
Joseph S. Myers
joseph@codesourcery.com