software breakpoints

[gurcei]

Let the app auto-step through code and stop upon hitting one of a list of software breakpoints the user has added.

For software breakpoint support:

• the system must be in trace mode, as set by the "t1" raw command.
• use the "break {addr}" command for adding software breakpoints
• use "breaks" to list all breakpoints
• use "bdel {breakno}" to delete a breakpoint
• use "cont" to let the app do its auto-step mode
• let CTRL-C break out of the "cont" loop

As for the hardware breakpoint support, I'll consider doing it this way:

• for the hardware breakpoint to trigger, the system must not be in trace mode, so assure it is turned off with the "t0" raw command. Once the hardware break hits, the system will automatically pause and switch to trace mode (t1).
• use the "hbreak {addr}" command for setting the single hardware breakpoint
• use "hbreaks" to list the current hardware breakpoint (there's only one)
• use "hbreak" or "hbdel" to delete it

[Ben-401]

from memory the fpga-side serial-debugger is tightly integrated with the cpu-core.
i would prefer a more significant seperation between the two (if possable).
in this regard, if/when the seperation occurs, your work in the m65dbg for breakpoints may need repairs.
all good for now though..

[gurcei]

Yep, fair enough. I was foreseeing a bit of repair ahead with the recent discussions about refining the comms protocol, so I'll do my best to keep m65dbg commands working nicely with any changes on the hardware.

[gardners]

I'm not sure that further separation is possible, while still maintaining
the functionality, and without adding additional hardware cost, or slowing
the interface down. I'm open to suggestions as to how we might improve it,
though.

On Wed, Aug 10, 2016 at 11:16 PM, Ben-401 [email protected] wrote:

from memory the fpga-side serial-debugger is tightly integrated with the
cpu-core.
i would prefer a more significant seperation between the two (if possable).
in this regard, if/when the seperation occurs, your work in the m65dbg for
breakpoints may need repairs.
all good for now though..

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#7 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAonT5N5QuDFT6Ey8pGplnw6_O0BYLJgks5qedY0gaJpZM4JfgjJ
.

[gurcei]

Some progress has been made with software breakpoints inside m65dbg. It evolved out of necessity of my debugging needs at the time, so I forgot all about the thoughts we had here.

Presently, it is just a single software breakpoint that can be set with "sbreak ", and hit with "sc" (soft continue).

Another nice shortcut way to do both in one hit is to say "sc " (soft-continue until it reaches this soft breakpoint).

I won't close this ticket for now though, as I might come back to the thoughts here, and the ideas of supporting multiple breakpoints.