johnl@esegue.segue.boston.ma.us (John R. Levine) (10/17/89)
In article <1989Oct16.225206.22386@paris.ics.uci.edu> Ron Guilmette <rfg@ics.uci.edu> 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". ... >I noticed that the i860 has this feature on-chip. ... >Now if we could just get support for such things via standard UNIX ptrace >calls, and then get the GNU Debugger (gdb) to actually bring such facilities >out to the user's level... Some of us low-budget types feel pretty lucky. 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. Astonishingly, AT&T System V/386 ptrace() lets you read and write the debug registers (take that, you Berkeloids) that control this swell feature. I keep meaning to teach gdb how to use them. Maybe somebody else already has. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl Massachusetts has over 100,000 unlicensed drivers. -The Globe
seanf@sco.COM (Sean Fagan) (10/20/89)
In article <1989Oct17.045410.399@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes: >>>"breakpoint at data address". ... >Some of us low-budget types feel pretty lucky. 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. >Astonishingly, AT&T System V/386 ptrace() lets you read and write the debug >registers (take that, you Berkeloids) that control this swell feature. >I keep meaning to teach gdb how to use them. Maybe somebody else already >has. This is a brief pseudo-plug, followed by a real question... Anyway: CodeView(tm) under SCO UNIX 3.2 uses the debug registers to set 'Watchpoints' and 'tracepoints.' I think it also uses other debug registers to set breakpoints. A problem with this is that there are only 4 register (of each kind, I believe: 4 code breakpoint and 4 data breakpoint, but I'm not sure), thus you can only set 4 breakpoints... BTW, it is a very nice feature. I first saw something like it in dbx on a Sun (trace <var>), but using it slowed it down incredibly (it had to single step, I believe). With codeview, it runs along at full speed until it accesses the variable. *Very* nice. Lots of other processors have these, of course, including, say, the NS32xxx series. My chief complaint is that they only catch a single address; I think they would have been much more useful if it had been <address, length>. For a real-world example, I could then tell codeview to stop whenever any element of a structure has changed. Anybody got a reason why it never seems to be implemented that way, other than not slowing it down (I would not be surprised if it slowed down memory accesses by 1 or 2 cycles)? -- Sean Eric Fagan | "Time has little to do with infinity and jelly donuts." seanf@sco.COM | -- Thomas Magnum (Tom Selleck), _Magnum, P.I._ (408) 458-1422 | Any opinions expressed are my own, not my employers'.