[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130331173518.GH30576@port70.net>
Date: Sun, 31 Mar 2013 19:35:19 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: pthread_getattr_np
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)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
