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.