From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3018 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: pthread_getattr_np Date: Sun, 31 Mar 2013 19:35:19 +0200 Message-ID: <20130331173518.GH30576@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1364751330 30051 80.91.229.3 (31 Mar 2013 17:35:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 31 Mar 2013 17:35:30 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3019-gllmg-musl=m.gmane.org@lists.openwall.com Sun Mar 31 19:35:57 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UMMAe-0007ia-N1 for gllmg-musl@plane.gmane.org; Sun, 31 Mar 2013 19:35:56 +0200 Original-Received: (qmail 5987 invoked by uid 550); 31 Mar 2013 17:35:31 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 5979 invoked from network); 31 Mar 2013 17:35:31 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3018 Archived-At: pthread_getattr_np is used by some libs (gc, sanitizer) to get the beginning of the stack of a thread it is a gnu extension but bsds have similar non-portable functions (none of them are properly documented) glibc: pthread_getattr_np freebsd: pthread_attr_get_np netbsd: pthread_attr_get_np and pthread_getattr_np openbsd: pthread_stackseg_np osx: pthread_get_stackaddr_np, pthread_get_stacksize_np solaris: thr_stksegment hp-ux: _pthread_stack_info_np (glibc and freebsd use locks to synchronize the reading of thread attributes, may matter for detach state) (glibc and openbsd try to get correct info for the main stack others don't) returning reasonable result for the main stack is not trivial (the stack starts at some unspecified address and can grow downward until the stack rlimit or some already mmapped region is hit) possible ways to get the top of the main thread stack: 1) /proc/self/maps (fopen,scanf,.. this is precise, glibc does this) 2) save the top address of the stack at libc entry somewhere (eg by keeping a pointer to the original environ which is high up the stack) this is a good approximation but underestimates top by a few pages 3) the previous approach can be tweaked: the real top is close so the next few pages can be checked if they are mapped (eg with madvise) and we declare the address of the first unmapped page as the top (usually this gives precise result, but when the pages above the stack are mapped it can overestimate top by a few pages) then the stack is [top-rlimit,top] (the low end should be tweaked when it overlaps with existing mappings, the current sp is below it or rlimit is unlimited) i looked at how the stack is layed out by the kernel: according to linux/fs/exec.c the stack top looks like ...|args|env vars|execed filename|(void*)0|(top) and then in linux/fs/binfmt_elf.c (libc entry)|argc|argv|environ|auxv|16byte random|capability string|... the top is page aligned and from args to the top it is at most 32 pages (ARG_MAX) the libc entry sp is saved by the kernel and it can be read out from /proc/self/stat (stackstart)