mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Szabolcs Nagy <nsz@port70.net>
To: musl@lists.openwall.com
Subject: pthread_getattr_np
Date: Sun, 31 Mar 2013 19:35:19 +0200	[thread overview]
Message-ID: <20130331173518.GH30576@port70.net> (raw)

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)


             reply	other threads:[~2013-03-31 17:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-31 17:35 Szabolcs Nagy [this message]
2013-03-31 18:07 ` pthread_getattr_np Rich Felker
2013-03-31 20:51   ` pthread_getattr_np Szabolcs Nagy
2013-03-31 21:00     ` pthread_getattr_np Rich Felker
2013-03-31 21:37       ` pthread_getattr_np Szabolcs Nagy
2013-03-31 23:31     ` pthread_getattr_np Szabolcs Nagy

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=20130331173518.GH30576@port70.net \
    --to=nsz@port70.net \
    --cc=musl@lists.openwall.com \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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 NNTP newsgroup(s).