lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) (10/20/89)
In article <1989Oct17.045410.399@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes: >>In article <6535@pt.cs.cmu.edu> lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes: >>>About the only hardware feature I used to pray for was "breakpoint at >>>data address". ... >The 80386 can trap up to four >memory addresses, separately monitoring each for fetch, read, or write. >When this feature is in use your program runs slower, but it's a heck of >a lot faster than instruction at a time tracing. Hmm, I wonder how much slower? The above quote from my posting leaves off the comment that it can be done *without* special hardware features. In particular, the infamous trap-after-every-instruction feature is a bad idea, because this "hardware assisted" method is sooo slooowwww. 1) I believe that Encore's debugger simply has a spare processor watch the location. 2) A compiler generating debug code, can put a special call at the front (and rear) of each subroutine. The debugger provides the routine that is called: if you ask to have a location monitored, then that's what the routine does. As debug services go, this takes very little space and very little time - especially on machines with lightweight call instructions. Admittedly, it can only say "the variable changed in procedure foo, between its call to baz and its call to bletch". But, when I used it, that was great information. 3) The debugger could protect the variable's page, and catch the page faults. Admittedly, a particularly popular page could cause a performance problem. However, several times, I was looking for one wild dereference into maybe four megabytes of tree. On a VAX, that one locked page would have taken up a whole 0.0001 of the address space. My point: there are a lot of ways to skin a cat, and extra hardware is usually only one of them. -- Don D.C.Lindsay Carnegie Mellon Computer Science
markm@hcr.UUCP (Mark Mendell) (10/27/89)
This is my turn for a pseudo-plug: DbXtra 2.1 (HCR's port of BSD dbx) on 386/IX also uses the 386 debug registers to tell when a variable has been changed (or accessed), and also to test when a given condition becomes true. I.e. stop if i > 99 A brief (and very unbalanced test) gave me a test case where the new version (using the debug registers) ran the test program 300 times faster than the old method of doing this in dbx, which is to stop after every statement, and then test the condition. I also found that the penalty for using the debug registers at all was about 3% slowdown. This is because the LE bit must be set in the debug control register, so that 'exact data breakpoint match' is true, and the data breapoints are reported on the instruction that causes them. I assume that this slows down the pipeline somewhat. Dbxtra 2.1 for 386/IX will be available in January '90. Does anyone know when the 386 debug registers dr4 and dr5 will be available? The 486? 586? It would be nice to be able to span more than 16 bytes worth of data for these breakpoints! -- Mark Mendell, HCR Corporation 130 Bloor St. W., Suite 1001, Toronto Phone: (416)-922-1937, Fax: (416)-922-8397 Usenet: ...!hcr!markm