23 Feb
2016
23 Feb
'16
3:09 p.m.
On Mon, 22 Feb 2016, Mouse wrote:
These and many of the other stop conditions could
possibly be subsumed
by a "stop when this expression evaluates true" facility, with
expression primitives capable of representing all the things you might
want to watch. It would of course be CPU-intensive if the expression
is complicated, but that's unavoidable, and I have occasionally wished
for "run until this number is greater than that number plus twice this
register" or the like, even if it runs multiple orders of magnitude
slower. (Not when running under RT-11, but that's mostly because I
have done little-to-no work under RT-11 at all.)
This is exactly how GDB's watchpoint facility works BTW. Except from the
very simple case of watching a memory location, which in some processors
can be delegated to a hardware watchpoint facility, GDB implements this by
single-stepping the debuggee repeatedly, which of course hits performance
enormously. Then, whether through single-stepping or as a result of a
hardware watchpoint hit, it stops the debuggee and returns control to the
user whenever the watchpoint condition evaluates to true. Any expression
valid in the high-level language chosen for debugging (which is usually
the same as one the debuggee has been compiled from) can be used as a
condition, also for breakpoints, and you can refer to hardware registers,
which are presented as special variables (side effects work too!).
As a matter of interest some embedded MIPS processors have more complex
hardware watchpoint support in which certain conditions can actually be
presented to hardware as a chain of prerequisites for a watchpoint hit.
This facility is available for JTAG debugging only and support has never
been implemented in GDB, although JTAG debugging itself is supported in
GDB with the use of a suitable remote debug stub (or more precisely GDB
does not care what it talks to as long as it speaks GDB's language, aka
Remote Serial Protocol).
FWIW,
Maciej