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/27/2018 04:03 AM, Adhemerval Zanella wrote:
> 
> 
> On 27/02/2018 07:53, Szabolcs Nagy wrote:
>> On 27/02/18 08:21, Florian Weimer wrote:
>>> On 02/22/2018 01:56 PM, Adhemerval Zanella wrote:
>>>>> Split stack support already requires a stack limit in the TCB.  This could be reused even if split stacks are not used.  We'd need to add another field for the other stack end, though.
>>>> Couldn't we embedded it on pthread_t instead? I rather avoid changing TCB, since it
>>>> requires changing the ABI for some architectures (aarch64 is an example where
>>>> split-stack field is being added in a different manner).
>>>
>>> It will be part of the ABI no matter where we put it.  I don't have a strong preference in this regard.
>>>
>>
>> i think the point is that you can add
>>
>> - a new function to query it
>> - or put it at a fixed offset from the tp.
>>
>> the later is a much uglier abi than a new symbol
>> (it requires different hack on all targets and
>> there is no documentation or any way to figure
>> out the offsets other than reading glibc code,
>> and much less likely that other libcs would add it)
> 
> Since it is not a performance critical one, I would recommend the former as well.
 
I agree. For things which are not performance critical
we should be creating an API.

In fact I consider a heinous crime for ASAN to have not
reached out to all C library vendors they interface with
to get an API to do what they want. Hacks like this come
back to bit all of us, and then we disappoint users and
take several cycles to fix things instead of having
implemented them correctly up front.

We are not blameless though. We are like the slowest project
in the world :-)

-- 
Cheers,
Carlos.