This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

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.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]