breakpoints & debugging

[Onkar Shinde]

Here are some comments regarding the breakpoints facility:

- it would be more intuitive, if breakpoints could also easily be added/removed (disabled) simply by clicking the mouse in the breakpoint column, this would be consistent with many other IDEs and programming environments.

- it would be very useful if breakpoints could not only be triggered on executing a certain line of code, but also on other events such as:

  - register access
  - memory access
  - port access
  - stack acess

Preferably, users would be able to parametrize their breakpoints, so that they could chose to register a breakpoint to track down register/memory/port/stack access, so that they could then specify to further customize the breakpoint, i.e. by picking applicable events (READ or WRITE access), and optionally by also specifying parameters for the value during the access.

This would allow a scenario where the user may specify:

breakpoint on register access (WRITE) "BD", value "400h"

The value could optionally be provided as a range or constraint, so that conditional breakpoints are possible:

breakpoint on register (READ|WRITE) "BD", value greater than 400h

This sort of breakpoint support would be very powerful and these types of breakpoints are in fact supported by many mainstream debuggers.

[Bug Importer (bug-importer)]

such custom breakpoints could preferably be presented in a list for breakpoints, along with a symbolic name/description for each breakpoint, as well as a possibility to enable/disable, and edit/delete these breakpoints.

[Bug Importer (bug-importer)]

ideally, such breakpoints could be connected to custom actions, too.
So that a breakpoint may not necessarily "break" program execution, but could for example also simply trigger a custom log message to be displayed in the log window, something along the lines of "branching to address in stack" - this would help debugging if users could specify custom breakpoint actions and parameters!

[Bug Importer (bug-importer)]

such conditional breakpoints that are based on and triggered by runtime data are commonly referred to as "data breakpoints" or "watchpoints": http://en.wikipedia.org/wiki/Breakpoint

[Bug Importer (bug-importer)]

Here's a short introduction about the concept of "watchpoints" for data access as they are being provided and used by gdb:
http://theory.uwinnipeg.ca/localfiles/infofiles/gdb/gdb_30.html#SEC30

[Bug Importer (bug-importer)]

Also, when improving GNUSim8085's debugging support, it would make sense to consider providing a facility to automatically unwind the stack, for example in order to obtain a "backtrace" to see how exactly a line of code ended up being executed, this could be easily based on the current stack data structure, which already internally keeps track of the nature of values pushed - so the simulator already knows about those values that are pushed by "call" and popped by "ret". Being able to interactively dump and inspect the call stack would thus be highly useful for debugging purposes.

[Bug Importer (bug-importer)]

more generally implemented, watchpoints could not only be specified with an address offset but also a size in bits or bytes, so that any read/write accesses to arbitrarily large types/data structures could be tracked just by defining the start of the data in memory and its size in bits/bytes.

This would not only facilitate watching statically defined data, but also dynamically created data structures that may simply not be available during the assembly process.

From an implementation point of view, there could be optional callbacks registered for read/writes and if the callbacks pointer is not NULL, it could be invoked in order to trigger the watchpoint

http://www.cs.dal.ca/studentservices/refcards/gdbref.pdf
http://www.delorie.com/gnu/docs/gdb/gdb_30.html
http://www.unknownroad.com/rtfm/gdbtut/gdbwatch.html