[net.arch] 286 Stack Overflow Detection

kendalla@iddic.UUCP (Kendall Auel) (09/10/85)

This is a correction/addition to my posting concerning the handling
of a stack overflow condition on the Intel 80286:

In order to switch stack segments in the midst of running a procedure,
a couple of very strict rules must be adhered to. 1) All data on the
stack may only be addressed using the "bp" register. This register
will be updated by the stack overflow exception handler. 2) At no time
may the stack pointer ("sp" register) or the "bp" register be saved
(in memory or in another register) and be assumed to be a valid address.

The main point of my original article was that a stack overflow need
not be a fatal condition on the 286, as others have stated. I have
presented one possible solution to the problem, and I suspect other
more workable solutions exist as well.


Kendall Auel
Tektronix, Inc.
Graphics Workstations Division

(These views are my own, etc...)

gnu@l5.uucp (John Gilmore) (09/14/85)

In article <2173@iddic.UUCP>, kendalla@iddic.UUCP (Kendall Auel) writes:
> In order to switch stack segments in the midst of running a procedure,
> a couple of very strict rules must be adhered to. 1) All data on the
> stack may only be addressed using the "bp" register. This register
> will be updated by the stack overflow exception handler. 2) At no time
> may the stack pointer ("sp" register) or the "bp" register be saved
> (in memory or in another register) and be assumed to be a valid address.

This means that you can't take the address of a local variable in C,
or allocate an array on the stack and set a pointer pointing into it
(or pass it as an argument).  This is useless for Unix or even for ANSI
standard C, so those environments would be stuck with 64K stacks.

Offhand I can't see a reason why it wouldn't work if you store 32 bit
pointers ("large model"), including the segment reg value.  (Saving
either bp or sp is a nono, but how about saving both as a single
quantity?)  The kernel would have to keep all the old seg reg values
still valid in the map when it expanded the stack, but that's just one
more case of the compiler people and the kernel people have to talk to
each other a lot on the 286.  Can somebody enlighten me why this
doesn't work?