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 22/02/2018 09:17, Florian Weimer wrote:
> On 02/22/2018 09:57 AM, Carlos O'Donell wrote:
>> On 02/22/2018 12:43 AM, Florian Weimer wrote:
>>> On 02/21/2018 10:57 PM, Adhemerval Zanella wrote:
>>>> 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.
>>>
>>> glibc does not know the stack boundaries, though. We do not require
>>> that applications use the glibc-allocated stack . (We do, however,
>>> require that applications use the glibc-allocated thread control
>>> block.)
>>
>> We know it in many cases.
>>
>> If you do not use the obsolete pthread_attr_setstackaddr(), and instead
>> use pthread_attr_setstack(), we know the start and end of the stack.
>
> This is not true. There are many stackful coroutine libraries which switch the stack. But maybe this does not matter, and reporting an approximate boundary is fine—the consumer for this API can simply check if the current stack pointer falls into those bounds, and if not, do something else.
I don't see this as being a blocker to provide such API, if program is not using
the provided expected thread boundaries provided by libc it will most likely
create false positives from sanitizers.
>
> 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).