[EMAIL PROTECTED] writes:
> Hardware implementation has a cost, too. You complain that debuggers use
> special instructions or more memory to do what they do. What do you think
> the hardware is going to do? For breakpoints, the hardware would have to
> keep track of your breakpoint list, and check every instruction as it runs.
> That would actually be *slower* than simply inserting a new instruction in
> the code.
I think that this is a little bit confused.
(let's continue to assume that we're running on a x86)
The hardware *does not* run in the following way:
again:
is the PC (program counter) at a breakpoint? if so, <break>
run the instruction at the PC
goto again;
Instead, the way debuggers typically implement breakpoints (*) is to
install a special instruction at a given instruction location (the
location of the breakpoint) (this is commonly done with ptrace()).
The original instruction at this location is saved (for later use).
The hardware runs as usual, running each instruction as fast as it can
(it does *not* look at some breakpoint table before running each
instruction). When the hardware gets to the special instruction, this
actually triggers a hardware trap. This is an exceptional situation.
The generation of a hardware trap triggers a trap-handling routine.
The routine, by virtue of the fact that if finds itself being
executed, knows that a breakpoint has been reached. It also knows
where the PC was when this happens.
<handwaving> The trap-handling routine, at this point, can cooperate
with the parent debugger. The original instruction can also be run
(since it was saved -- the routine can put it back, put a breakpoint
at the next instruction, run the original instruction, break, and then
re-install the special <break> instruction, so as to preserve the
breakpoint *and* to preserve the program's semantics.
The point here is that the program can be run at full-speed *and* be
debugged at the same time.
(*) I wrote a debugger like this once at UNH. It was one of my
favorite programs -- ever.
--kevin
--
Kevin D. Clark (CetaceanNetworks.com!kclark) |
Cetacean Networks, Inc. | Give me a decent UNIX
Portsmouth, N.H. (USA) | and I can move the world
alumni.unh.edu!kdc (PGP Key Available) |
*****************************************************************
To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.
*****************************************************************
