| Related articles |
|---|
| [4 earlier articles] |
| Debuggers fabio@dcs.edinburgh.ac.uk (1991-08-08) |
| Re: debuggers zstern@adobe.com (1993-11-11) |
| Re: debuggers shyamal@seas.smu.edu (1993-11-11) |
| Re: debuggers wjw@eb.ele.tue.nl (1993-11-11) |
| debuggers ssimmons@convex.com (1993-11-11) |
| Re: debuggers sommerfeld@apollo.hp.com (1993-11-11) |
| Re: debuggers sean@PICARD.TAMU.EDU (1993-11-12) |
| Re: debuggers henry@zoo.toronto.edu (1993-11-14) |
| Re: debuggers zstern@adobe.com (1993-11-15) |
| Newsgroups: | comp.compilers |
| From: | sean@PICARD.TAMU.EDU (buzzard) |
| Keywords: | debug |
| 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
scenario:
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.
Sean Barrett
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.