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
On Wed, Feb 21, 2018 at 9:58 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> 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.
Yes.
But we keep finding ourselves in this situation from version to version.
>
> 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.
LLVM has the sufficient tests, which is how we've learned about the problem.
Do glibc developers run LLVM tests?
If not, is it possible to change this?
GCC has a completely different test suite.
I've made several attempts to convince the GCC developers to use the
LLVM test suite and
either have not heard back or heard "no" w/o much explanations.
I've lost interest in this battle since then.
>
> 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 :-)
Sure.
>
>> 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.
We already do that :(
> You have no
> guarantees from us that these structures will not change.
Which is why I've been asking for an interface.
>
> 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.
Perhaps others. I tried hard, and failed. Now let someone else try.
Yes, this means that asan+dtls will remain broken for the users of 2.25.
When enough users yell at us, we'll put another hack (which will force
them to upgrade to fresh LLVM, of course).
It will then take GCC some time to adopt this hack, and GCC users will
have to wait for some more time.
>
> 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.