See below
Simon Wood
PS. Please only reply to the list OR to me personally... I only need 1 copy.
Hardware Engineer
Pace Micro Technology plc
Victoria Road, Saltaire, Shipley
West Yorkshire, BD18 3LF
Tel : +44(0)1274 532000 Fax: +44(0)1274 532029
This E-Mail and any attachments hereto are strictly confidential and
intended solely for the addressee. If you are not the intended addressee
please notify the sender by return and delete the message. You must not
disclose, forward or copy this E-mail or attachments to any third party
without the prior consent of the sender.
> -----Original Message-----
> From: Greg Haerr [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, June 24, 1999 9:19 PM
> To: 'Simon Wood'; [EMAIL PROTECTED]
> Subject: RE: ELKS: Application Code, Data, Heap and Stack Size??
>
>
> : Is there any checking on the Stack Size (to prevent it over writing
> : the stack)?
> :
>
> Not by bcc. Let me know if you'd like me to add stack overflow
> checking.
>
>
>
> : Psion (on SIBO) seem to place a fixed stack at the bottom of the data
> : segment (which grows down towards DS:0000), then initialised data, then
> : un-initilised and then heap (which grows up). This has the advantage
> that
> : the 'hardware protection' can detect if the application writes outside
> it's
> : allocated data segment and halt the application. But the disadvantage
> that
> : the maximum stack size MUST be allocated at compile time.
> :
>
> Why do we need to reorient the stack placement in the DS segment
> in order to use the hardware protection feature? I don't seem to be
> getting this.
>
[<Simon Wood>]
The only advantage I can think of is that the hardware protection could
catch a stack or heap overflow BEFORE any data was overwritten, and
therefore possible prevent other corruption around the system.
In order to put the stack here you have to specify a couple more parameters
for LD86 (as I've done in the Psion Port's Makefile).
This really doesn't make much difference to the system stability, if code is
written so that it overflows its stack then it will crash... simple. The
added complexity of change all existing applications and convincing all new
applications to do it this way is probably too much effort.
If we do (init, un-init, stack, heap) we can do this is the kernel, it would
give us the ability to grow the heap if need be (without changing the
addresses) and should the stack need to be grown it would have to be resized
and relocated (though I think this would be rare).
So form of stack check would be nice, every function call seems a little to
much for a lowly 8086. How about on task switch or even interrupt (or is
this too late)? If the chosen size for the stack is too small, it can be
cured by modifying the binary rather than a full recompile.
> Greg
