> | Hi.  Re: http://mail-index.netbsd.org/tech-kern/2002/02/03/0002.html ,
> | about STACK_GROW, STACK_SHRINK, STACK_ALIGN, STACK_ALLOC and STACK_MAX.
> |
> | At least gdb likes to define its own (and different) STACK_ALIGN.
> | Should I append __ to these macro names or wrap them in _KERNEL?
> 
> Should we consider moving the stack manipulation into MD code?
> For instance, sparcs have a stack pointer bias of 2047 for 64-bit
> stacks but no bias for 32-bit code, so you need to conditionally
> add or subtract the bias properly when manipulating the stack 
> pointer or stack objects.  Likewise 32-bit stacks require 8-byte
> alignment and 64-bit stacks require 16-byte alignment.  It's not 
> immediately apparent how your macros would address those issues.

My take on the situation:

- Right now the MI kernel never builds stack frames, which is good, 
  because these vary wildly with architecture, and trying to come
  up with abstract macros to describe them would be tough.

- What the MI kernel does do is, in a few places it makes pointers
  into a stack, usually for the purpose of copying data there.  For 
  this, all I think you need are macros like the ones I have proposed:
  macros that move a stack pointer in the right direction.

Ya, __STACK_ALLOC could maybe do more with respect to alignment.  It 
might take a struct proc * and have an MD definition that would return
properly aligned pointers for the process.  

But then to do things totally right I think you'd have to go and make 
sure to use __STACK_ALLOC or a related alignment macro in lots of new 
places, like say, all throughout the copyargs functions.  With my simple 
approach now I get to leave that code alone :)

Here's my proposed patch of 258 lines, comments anyone?

ftp://ftp.netbsd.org/pub/NetBSD/misc/fredette/stackdir/stackdir-20020707.patch

Matt

-- 
Matt Fredette