On Wed, Sep 24, 2003 at 11:04:36AM -0400, Andrew Brown wrote:
> it would also keep stack segment separate and distinct from other
> segments in the core dumps.

the information on what's a stack and what's not will already be in
the core dump in the pthreads internal datastructures, right?
gdb already has to know about that to be able to do backtraces
of the various user threads.


> >(There are also yellow-zone stack tricks that could be useful, but I
> >think those could be managed in userlevel with existing mprotect() and
> >faulting-address information).
> 
> it's also perhaps worth mentioning that freebsd has a MAP_STACK flag
> to mmap() that, if i correctly has the effects that:
> 
> * "addr" is the "stack top", as is the return address, meaning that if
> you write to addr, you'll fault (unless there's something already
> there), but that you can walk backwards "size".
> 
> * the region is expected to grow backwards from top to bottom (ie, you
> decrement your "stack pointer" and push values in when using it).
> 
> to put this another way:
> 
> 	void *a, *b;
> 	a = mmap(0x40000000, 4096, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0);
> 	b = mmap(0x40000000, 4096, PROT_READ|PROT_WRITE, MAP_STACK, -1, 0);
> 
> with both succeed and return 0x40000000.  the first call causes the
> page at 0x40000000 to be allocated and the second call causes the page
> *prior* to 0x40000000 to be allocated.  note that i'm basing this on
> skimming the code and the man page, not on actual experience.
> 
> it might be worth considering bringing this in, at least for emulation
> purposes...

if this can be handled entirely in the emulation code, that would be fine.
I'd rather not clutter up the UVM code with it, though.  our amap-merging
code probably works well enough (or will, once we fix a couple bugs) that
explicitly telling UVM it's a stack won't gain anything.

-Chuck