|[4 earlier articles]|
|Debuggers firstname.lastname@example.org (1991-08-08)|
|Re: debuggers email@example.com (1993-11-11)|
|Re: debuggers firstname.lastname@example.org (1993-11-11)|
|Re: debuggers email@example.com (1993-11-11)|
|debuggers firstname.lastname@example.org (1993-11-11)|
|Re: debuggers email@example.com (1993-11-11)|
|Re: debuggers sean@PICARD.TAMU.EDU (1993-11-12)|
|Re: debuggers firstname.lastname@example.org (1993-11-14)|
|Re: debuggers email@example.com (1993-11-15)|
|Organization:||Fraternity of Avian Deists|
|Date:||Fri, 12 Nov 1993 03:50:18 GMT|
It might be worth considering giving some compiler support to doing soft
data watchpoints, by providing extra debug information to support this
Rather than single stepping every instruction executed, and checking the
location, the debugger can:
1. single step conditional flow-control operations
2. put breakpoints after the next instruction that writes to memory
Using these two is sufficient to reducing the number of single-step
operations to (effectively) the number of conditional branches and memory
writes, which I'd expect to be about an order of magnitude better.
If a compiler actually wants to directly support it, every memory write
could be made a function call, with the obvious cost in performance, or
every memory write could have a nop (or multiple nops as necessary) after
it which the debugger can backpatch with the same function call. This
costs some performance (the extra nops), and it would take quite a while
for the debugger to patch every write-nop in the program when the debugee
(?) sets a data watchpoint, but it'd be a bit faster.
Using the hardware is even better, but I'm not holding my breath, given
the ubiquitousness of portable GNU software over platform-specific tools.
Return to the
Search the comp.compilers archives again.