This is the mail archive of the libc-alpha@sourceware.org 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] |
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.
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.
Thanks, Florian
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |