Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site l5.uucp
Path: utzoo!linus!decvax!decwrl!sun!l5!gnu
From: gnu@l5.uucp (John Gilmore)
Newsgroups: net.arch
Subject: Re: 286 Stack Overflow Detection
Message-ID: <118@l5.uucp>
Date: Sat, 14-Sep-85 05:01:57 EDT
Article-I.D.: l5.118
Posted: Sat Sep 14 05:01:57 1985
Date-Received: Sun, 15-Sep-85 05:14:38 EDT
References: <2173@iddic.UUCP>
Organization: Ell-Five [Consultants], San Francisco
Lines: 21
Summary: Do 32-bit pointers ameliorate the problem any?

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?


Brought to you by Super Global Mega Corp .com