This is the mail archive of the
mailing list for the glibc project.
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
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.