Debugger watchpoints in UNIX ?

Michael Meissner meissner at osf.org
Sat Mar 10 09:14:44 AEST 1990


In article <3004 at auspex.auspex.com> guy at auspex.auspex.com (Guy Harris)
writes:

| >At least System5.2 and beyond do watchpoints.
| 
| Yes, but so does "dbx".  That wasn't what he was asking:
| 
| > Has anybody heard of an efficient implementation of watchpoints, i.e. 
| > breakpoints activated whenever an arbitrary position in memory (e.g. a 
| > field of a dynamically allocated structure) changes value ?
| > Both dbx and saber can do something similar, but with horrendous 
| > performance penalty ("stop address" commands).
| 
| and, since the "sdb" manual says:
| 
| >	       Since this command is done by software, it can be very slow.
| 
| that doesn't fit his criteria.  In fact, the "sdb" version is slow for
| the same reason the "dbx" one is slow - they both basically single-step
| the program and check the variable after each instruction.
| 
| The VMS scheme, to which he alluded, is to set the page containing the
| variable non-writeable, and catch the protection faults (actually, it
| may made it inaccessible, due to problems in, say, the 11/750's handling
| of protection faults that prevents it from being able to restart the
| instruction that faulted).  Current UNIX systems generally don't let you
| do this.

If I remember correctly, Data General's DG/UX had it's xtrace system
call which let the debugger map out the page, and get awoken when a
page fault occured (the basic gist is to leave the page unmapped, and
simulate the instruction the old slow way, and check the variable).

I wonder if anybody on a real MACH system has modified the debugger to
start the process with the external pager pointing to the debugger
(under MACH user processes can handle page faults for other processes
if granted permission).
--
Michael Meissner	email: meissner at osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA

Catproof is an oxymoron, Childproof is nearly so



More information about the Comp.unix.questions mailing list