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 09:34:39 +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 #2 from Kostya Serebryany <konstantin.s.serebryany at gmail dot com> ---
(In reply to Rich Felker from comment #1)
> Do you want to get the information for the calling thread, or for an
> arbitrary target thread? The latter is much harder.
Thanks for clarification. We need only the simple case:
find the stack and tls boundaries for the calling thread.
>
> For the main thread, determining its stack extents is difficult and libc
> really has nothing to do with it; the kernel is mostly responsible. One end
> is fixed and libc could easily record that and provide it,
Even getting one end would be helpful.
We can continue to deduct the second end from /proc/self/maps and getrlimit
> but the moving
> end is hard to measure except by the main thread itself where you can just
> look at the current value of the stack pointer. Of course one issue is
> whether you want the _current_ extents of the stack or the maximum possible
> extents.
We need the maximum possible.
Of course, this is not very useful if the stack is unlimited.
> Getting the latter is difficult and may even be impossible under
> certain conditions where setrlimit has been used to adjust it during the
> program's lifetime.
--
You are receiving this mail because:
You are on the CC list for the bug.