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
