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

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 20/02/2018 17:24, 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?
> 
> 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.
> 
> Thanks!

The thread properties API is too late for 2.25 unfortunately, our policy is 
to not change and ABI (even by adding new symbol) on released versions.

Similar for your original bug report, most likely this discussion got stalled
because lack of cycles from glibc developers.  However based on recent updates
from Carlos in BZ#16291 [1] I think a thread reflection ABI is something not
only sanitizer would benefit. Also you sanitizer might face more issues with
TLS size calculation now that we changed stack size calculation (BZ#22637).

My view off the ABI your proposed is for stack boundaries and static TLS part
it seems reasonable: both query functions initial descriptions are 
straightforward and internal implementation should require only reading some
internal states.

For dynamic TLS I think the interposable symbols seems the better alternative 
(since you already listed the issues with callback option) and the extra
PLT calls for the symbols should be ok.  

Now for thread exit I think callback as is described should have its semantic
better described with something similar to pthread_atfork. The wording used
in first paragraph describe per-thread callbacks which will be called only
by the thread registering them, however the following sentence defines callbacks
should be register before thread creation. Also this restriction seems very
specific to sanitizers, although I do not have a strong opinion whether we
should allow new registrations after thread creation (for instance
pthread_atfork does not have this restriction). Finally, since the idea is
to exports a GNU abi, we will need a better name.

Carlos, I am adding you on CC because I noted you commented recently on
BZ#16291 about rust requirements of similar API, so it would be good if
current proposal is adequate to rust as well.

[1] https://sourceware.org/glibc/wiki/Tools%20Interface%20NG