[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130331210005.GJ20323@brightrain.aerifal.cx>
Date: Sun, 31 Mar 2013 17:00:05 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: pthread_getattr_np
On Sun, Mar 31, 2013 at 10:51:39PM +0200, Szabolcs Nagy wrote:
> > In practice, it seems like GC applications only care about the start
> > (upper limit) of the stack, not the other end; they use the current
> > stack pointer for the other limit. We could probe the current stack
> > pointer of the target thread by freezing it (with the synccall magic),
> > but this seems like it might be excessively costly for no practical
> > benefit...
>
> eg. address sanitizer creates a shadow map for the stack so
> at least it needs a reasonably sized upper bound on the
> stack size (but it does the /proc parsing magic itselfs for
> the main thread at startup so we don't have to support that)
>
> if the lowend is not used otherwise then we can give arbitrary
> result (eg always returning highend-5MB or using the rlimit
> truncated to some value when it's unlimited)
>
> all the calls to this function seem to use pthread_self()
> at thread creation or startup time, so synccall is probably
> not needed to get a sp
I just meant if we want the API to work in general...
> to get a 'precize' lowend one can:
> 1) parse /proc/self/maps which gives the current [low,high] mapping
> and 'prev' the high end of the last mapping below the stack
> 2) if we are the main thread check if low <= sp <= high
> 3) check rlimit
Parsing /proc/self/maps is utterly useless for non-main-thread. Unless
the thread has a guard page, its stack mapping can be adjacent to
another thread's stack mapping, and thus they can get merged into a
single mapping.
Rich
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.
