Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!agate!eris.berkeley.edu!mwm
From: mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer)
Newsgroups: comp.sys.amiga
Subject: Re: MANX vs. Lattice memory breakpoints
Message-ID: <26115@agate.BERKELEY.EDU>
Date: 8 Jul 89 01:53:41 GMT
References: <18346@usc.edu>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer)
Organization: Missionaria Phonibalonica
Lines: 32

In article <18346@usc.edu> papa@pollux.usc.edu (Marco Papa) writes:
<OK. I've my foot in my mounth :-) I must have been drinking beer too much 
<lately (I started again at DevCon '89). Anyway, Aztec's SDB DOES have a 
<memory watchpoint command, though admittedly is the most primitive of
<all. The syntax is:
[stuff deleted]
<SDB does not call them "memory change Breakpoints" as in Aztec's DB, but
<instead calls them "expression change" breakpoints.

From the description, it looks like the SDB "expression change"
breakpoints are doing something different from CPR's watch breaks. To
wit, SDB just checks the expression after the generated code would
have changed it; CPR checks the memory after every instruction (or
something along those lines). If this assumption is false, ignore the
rest of this.

For general debugging, what SDB does is actually better - you can find
the piece of your code that is in error. On the other hand, for
finding stray pointer bugs (in my opinion, the hardest kind of bug to
find), you need what CPR is doing. It goes like this:

Verify code is correct at program startup. Run until you die, and
notice that code has changed. Restart, set watchpoint on code that
changed, and run until it changes. You now have a pointer to the code
that has the stray pointer bug in it.

	<mike
--
When all our dreams lay deformed and dead		Mike Meyer
We'll be two radioactive dancers			mwm@berkeley.edu
Spinning in different directions			ucbvax!mwm
And my love for you will be reduced to powder		mwm@ucbjade.BITNET