This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/16291] feature request: provide simpler ways to compute stack and tls boundaries
- From: "konstantin.s.serebryany at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 04 Dec 2013 10:24:31 +0000
- Subject: [Bug libc/16291] feature request: provide simpler ways to compute stack and tls boundaries
- Auto-submitted: auto-generated
- References: <bug-16291-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=16291
--- Comment #4 from Kostya Serebryany <konstantin.s.serebryany at gmail dot com> ---
> Can you clarify why you need to know the max size the stack might grow to,
> rather than the currently valid stack range? The latter would be much easier
> to obtain, and the former could (I think) become wrong if the application
> uses setrlimit between the time the stack size is obtained and the time your
> code needs to know it.
Our code computes the stack bounds at thread initialization and never computes
them again for performance reasons: the bounds are needed in the
frame-pointer-based unwinder which needs to know the stack bounds,
and we call the unwinder on every malloc/free, so this is hot.
And we don't want to have special code like "if (in_main_thread)" in hot
places.
We need the stack bounds in a few other less performance-critical places too.
Anyway, the moving end of the main thread's stack is the least of our concerns,
tls size and non-main-thread stack bounds are more painful.
--
You are receiving this mail because:
You are on the CC list for the bug.