From: "Charles Sandmann" <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: CWSDPMI/DJGPP integration [was Re: Peculiar behavior of program.]
Date: Sat, 30 Jun 2001 13: 7:45
Organization: Aspen Technology, Inc.
Lines: 28
Message-ID: <3b3dcf21.sandmann@clio.rice.edu>
References: <3b3bcc05 DOT sandmann AT clio DOT rice DOT edu> <3b3c14b3 DOT 264226436 AT news DOT primus DOT ca> <3b3bd249 DOT sandmann AT clio DOT rice DOT edu> <3b3d9a68 DOT 364006408 AT news DOT primus DOT ca>
NNTP-Posting-Host: dcloan.hou.aspentech.com
X-Trace: selma.aspentech.com 993926702 27248 10.32.115.107 (30 Jun 2001 18:45:02 GMT)
X-Complaints-To: postmaster AT aspentech DOT com
NNTP-Posting-Date: 30 Jun 2001 18:45:02 GMT
X-NewsEditor: ED-1.5.8
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

> >This won't catch huge overruns, but if you write-protect the entire text
> >section you will at least prevent overwrite of executable code and catch
> >errors sooner with correct error messages.
> 
> For non-self-modifying-code (and self-modifying is rare these days --

The problem is hand written assembler which put data values in the .text
section.  In particular, exceptn.s stores some values for exceptions and
interrupts next to the code so it can be locked by DPMI in a single call.
(It also helps makes sure exceptions/tracebacks work or not - if you trash
the couple Kb where all this lives nothing works).  My fault - I wrote the
first version around 7 years ago.  I've always known this would need to be
fixed if we set .text to be read only - but until this recent thread noone
seemed to think it was worth the effort. There are probably a few other values
in other assembler modules also that would need to be changed.

If we locked all the .text section we would potentially break other modules
that get linked in that have been written that way over the years too.  
So, it would probably be best to put the exception handlers and code needed
into their own section - which means linker script changes, etc.  Not 
impossible, but not worth my effort for the one in thousand program that
trashes the memory space such that the exception handler won't run.  Since
most DPMI providers don't even support making the memory read only anyway -
the value becomes zero for many common environments (Windows).

Low effort fixes - setting bottom of stack uncommitted - this would
catch recursive programs that didn't jump down too much stack at once
and skip the uncommitted section.