Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site peora.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!petsd!peora!jer From: jer@peora.UUCP (J. Eric Roskos) Newsgroups: net.arch Subject: Re: Where to do stack checking, etc. Message-ID: <1599@peora.UUCP> Date: Mon, 9-Sep-85 08:29:00 EDT Article-I.D.: peora.1599 Posted: Mon Sep 9 08:29:00 1985 Date-Received: Wed, 11-Sep-85 05:34:14 EDT References: <796@kuling.UUCP> <1713@orca.UUCP> Organization: Perkin-Elmer SDC, Orlando, Fl. Lines: 49 > The MMU is the answer. I disagree with this. Unless you design your microprocessor architecture from the beginning to require an MMU. I was thinking about this question this weekend while trying to debug two very frustrating errors in a C program I was writing on my IBM PC (a UUCP- interfacing mailer). There were two things badly needed. 1) The ability to trap when JUST ONE particular address was generated as a data reference. There was this pointer, somewhere in this 80K program, which was overwriting part of an error message, so that a garbage character showed up whenever the error message came out. Apparently it was just using the byte in the error message as the location for a variable, instead of the byte it was supposed to use, because the program ran perfectly -- it just had this strange character in the middle of the error message. Now, if I could just have had the machine trap when that character was written to, I could have found out immediately where the error was. As it was, I still don't know where the error is... and probably will have to spend several hours hunting for it. This isn't such a major addition to the microprocessor; and the problem it solves is not that uncommon, and is one of the most difficult to debug. 2) Checking for stack integrity. In this same program, a return address on the stack was getting overwritten, causing the program to branch off into the data when some subroutine returned. Finding this required putting in some "I'm returning now...now I'm back" messages in a number of routines to discover which one actually was doing it. This one is a little harder to implement, but certainly would help.* The reason I say I disagree with the "in the MMU" approach is that currently most people treat MMUs as optional devices. This means that any application in which you use a microprocessor but don't use an MMU won't have access to such facilities; and I think that for microprocessors, the non-MMU applications probably far exceed the ones that use MMUs (I'm referring here to the use of microprocessors in controllers, etc.). ---------- *I'm sure at least someone is wondering what the cause of this error was... Well, it turns out that with this particular C compiler, if you give certain invalid values to the "mode" parameter of the creat() system call, it overwrites the stack... don't ask me why... -- Shyy-Anzr: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642