public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "konstantin.s.serebryany at gmail dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug libc/16291] feature request: provide simpler ways to compute stack and tls boundaries Date: Wed, 04 Dec 2013 09:34:00 -0000 [thread overview] Message-ID: <bug-16291-131-EZl2hcBT9t@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-16291-131@http.sourceware.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.
next prev parent reply other threads:[~2013-12-04 9:34 UTC|newest] Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-12-04 4:49 [Bug libc/16291] New: " konstantin.s.serebryany at gmail dot com 2013-12-04 9:19 ` [Bug libc/16291] " bugdal at aerifal dot cx 2013-12-04 9:34 ` konstantin.s.serebryany at gmail dot com [this message] 2013-12-04 9:56 ` bugdal at aerifal dot cx 2013-12-04 10:24 ` konstantin.s.serebryany at gmail dot com 2013-12-04 14:35 ` neleai at seznam dot cz 2013-12-04 14:49 ` konstantin.s.serebryany at gmail dot com 2013-12-04 15:46 ` bugdal at aerifal dot cx 2013-12-04 17:20 ` konstantin.s.serebryany at gmail dot com 2013-12-04 17:33 ` bugdal at aerifal dot cx 2013-12-05 3:54 ` konstantin.s.serebryany at gmail dot com 2013-12-11 11:01 ` konstantin.s.serebryany at gmail dot com 2013-12-11 15:14 ` bugdal at aerifal dot cx 2014-01-16 15:07 ` carlos at redhat dot com 2014-01-22 8:50 ` eugeni.stepanov at gmail dot com 2014-01-22 19:54 ` earthdok at google dot com 2014-01-23 15:45 ` konstantin.s.serebryany at gmail dot com 2014-01-23 15:57 ` konstantin.s.serebryany at gmail dot com 2014-01-23 16:07 ` ppluzhnikov at google dot com 2014-01-24 8:46 ` konstantin.s.serebryany at gmail dot com 2014-01-27 1:28 ` bugdal at aerifal dot cx 2014-01-27 7:16 ` konstantin.s.serebryany at gmail dot com 2014-01-29 10:00 ` konstantin.s.serebryany at gmail dot com 2014-01-29 10:26 ` bugdal at aerifal dot cx 2014-01-29 10:40 ` konstantin.s.serebryany at gmail dot com 2014-01-29 14:25 ` bugdal at aerifal dot cx 2014-01-29 15:23 ` konstantin.s.serebryany at gmail dot com 2014-01-29 18:21 ` bugdal at aerifal dot cx 2014-01-29 18:35 ` konstantin.s.serebryany at gmail dot com 2014-01-29 18:50 ` earthdok at google dot com 2014-01-30 5:10 ` bugdal at aerifal dot cx 2014-01-30 5:13 ` konstantin.s.serebryany at gmail dot com 2014-01-30 19:06 ` earthdok at google dot com 2014-01-30 19:21 ` carlos at redhat dot com 2014-01-30 19:43 ` earthdok at google dot com 2014-01-31 5:05 ` konstantin.s.serebryany at gmail dot com 2014-01-31 5:31 ` carlos at redhat dot com 2014-01-31 5:50 ` konstantin.s.serebryany at gmail dot com 2014-01-31 6:08 ` carlos at redhat dot com 2014-01-31 7:02 ` konstantin.s.serebryany at gmail dot com 2014-01-31 8:57 ` carlos at redhat dot com 2014-01-31 19:00 ` carlos at redhat dot com 2014-01-31 19:23 ` fche at redhat dot com 2014-01-31 19:40 ` bugdal at aerifal dot cx 2014-01-31 20:43 ` carlos at redhat dot com 2014-01-31 22:33 ` earthdok at google dot com 2014-02-03 8:14 ` konstantin.s.serebryany at gmail dot com 2014-02-03 9:11 ` octoploid at yandex dot com 2014-02-03 14:35 ` carlos at redhat dot com 2014-02-03 15:59 ` bugdal at aerifal dot cx 2014-02-04 14:18 ` konstantin.s.serebryany at gmail dot com 2014-02-04 14:30 ` joseph at codesourcery dot com 2014-02-04 18:50 ` bugdal at aerifal dot cx 2014-02-04 19:08 ` konstantin.s.serebryany at gmail dot com 2014-04-04 8:50 ` konstantin.s.serebryany at gmail dot com 2014-04-04 20:43 ` carlos at redhat dot com 2014-04-22 10:24 ` konstantin.s.serebryany at gmail dot com 2014-06-13 11:48 ` fweimer at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-16291-131-EZl2hcBT9t@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).