Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!psuvax1!rutgers!maverick.ksu.ksu.edu!castor!jxf
From: jxf@castor.cis.ksu.edu (Jerry Frain)
Newsgroups: comp.sys.mac.programmer
Subject: Re: A use for protected mode after all
Message-ID: <1990Nov30.052240.1799@maverick.ksu.ksu.edu>
Date: 30 Nov 90 05:22:40 GMT
References: <2382.2754d79e@waikato.ac.nz> <1990Nov29.025924.7662@maverick.ksu.ksu.edu> <4857@husc6.harvard.edu>
Sender: news@maverick.ksu.ksu.edu (The News Guru)
Organization: Kansas State University, Dept. of Computing and Information Sciences
Lines: 52

In article <4857@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes:
>In article <1990Nov29.025924.7662@maverick.ksu.ksu.edu> jxf@castor.cis.ksu.edu (Jerry Frain) writes:
>
>>I am not sure what you are asking here.  The debugger is an application
>>like any other, I hope you agree.  Quite often, ensuring the integrity
>>of the debugger is not as important as protecting the data of other
>>programs running on the system (e.g. - the OS).
>
>	I disagree. A debugger is definitely not "an application like
>any other".

My original point was that protecting the integrity of the debugger's
memory space is no more important than protecting the memory space
of other programs, in particular, the OS.  IN THIS RESPECT, the debugger
is no different from any other program.  To argue against this point is
absurd.

>	If a debugger can't modify other memory spaces, then its usefulness
>as a tool is severely limited - a debugger will typically need to set break-
>points, and edit memory, as part of the development cycle.

Truly this is the primary objective of the debugger.  This can also be
accomplished without giving the debugger free reign over the machine;
most modern multitasking OSs support debugging activity while
simultaneously providing memory protection for other processes quite well.

Supporting the principle that all programs may run rampant throughout
the entire range of memory offered by the machine, while other programs
are attempting to use this memory, is ludicrous.  The debugger should
operate under the grace of the OS, not on the same level of the OS.

>I believe that software that doesn't crash in the first place is the best
>way to go - whether it stomps on other parts of the system or not, a
>crash interferes with the user's ability to get work done, and therefore
>it is a good thing to avoid.

Personally, I'd rather have a crash than have a program "stomp on other
parts of the system."

Encountering a dangling pointer which misbehaves only enough to go out
and twiddle with a couple of bits in, say, my hard disk driver, _can_
be worse than an outright crash *or* writing in the memory space of my
favorite debugger.

  --Jerry

--
Jerry Frain -- Systems Programmer               Kansas State University
                                        Department of Computing & Info Sciences
Internet : jxf@cis.ksu.edu                         Manhattan, Kansas
UUCP     : ...!rutgers!ksuvax1!jxf