On Wed, 7 May 2003 12:01:14 -0700, Dave Hansen wrote:
> Jonathan Lundell wrote:
> > One thing that would help (aside from separate interrupt stacks)
> > would be a guard page below the stack. That wouldn't require any
> > physical memory to be reserved, and would provide positive indication
> > of stack overflow without significant runtime overhead.
>
> x86 doesn't really have big physical shortages right now. But, the
> _virtual_ shortages are significant. The guard page just increases the
> virtual cost by 50%.
Different people have different constraints. :)
For me, physical memory is low while virtual memory is abundant. But
even in your case, the guard page might be an acceptable evil during a
(hopefully short) transition time.
> The stack overflow checking in -mjb uses gcc's mcount mechanism to
> detect overflows. It should get called on every single function call.
Nice trick. Do you have better documentation on that machanism than
man gcc? The paragraph to -p is quite short and I cannot make the
connection to the rest of the patch immediately.
Jörn
-- Optimizations always bust things, because all optimizations are, in the long haul, a form of cheating, and cheaters eventually get caught. -- Larry Wall - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 07 2003 - 22:00:33 EST