Re: pthread_getattr_np

[Rich Felker <dalias@aerifal.cx>]

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