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

[Zack Weinberg <zackw at panix dot com>]

On Wed, May 9, 2018 at 8:14 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 05/09/2018 12:42 AM, Konstantin Serebryany wrote:
>> 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.
...
> 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.
...
> In the meantime, I agree with Joseph: We should paper over issues with the
> current approach with more testing.

I wonder how far we could get with black-box testing.  If the main
glibc testsuite compiled and ran some programs with ASan enabled,
programs that just expressed variations on the theme of "this program
should work correctly under ASan instrumentation", wouldn't that
sidestep the question of how ASan should actually do what it does, but
still allow us to detect catastrophic breakage like what prompted this
discussion?  It might be redundant to what a buildbot that ran the
entire testsuite under ASan instrumentation would accomplish, but it
would also not involve someone making the indefinite time commitment
involved in running a buildbot, so it might actually happen in the
near future?

zw