[hatari-devel] DSP debugging and breakpoints
npomarede at corp.free.fr
npomarede at corp.free.fr
Sat Jun 6 00:19:48 CEST 2009
On Fri, 5 Jun 2009, Eero Tamminen wrote:
> Btw. I thought a bit more about the register value conditions on breakpoints
> and they could actually be doable. debugui.c could parse the condition
> string given to breakpoint or single step command:
> db <address> [
> <register> <comparison> <value>
> [ | <register> <comparison> <value> ]
> [ & <register> <comparison> <value> ]
> where condition could be one of these:
> <, >, =, !
> like in:
> db 01b4 A1 > 1000 & D0 = 20
That's the idea I had when thinking about the 68000 breakpoints.
Possible extensions I saw were also :
- add a .b .w .l suffix after the register name to limit the size
of the comparison.
- use the () syntax as in 68000 to indicate "read the memory pointed by
- in your db example, don't specify an address, but make it optional by
using a more generic approach using the name 'pc' ; so setting a
breakpoint would not be "db <addr>" but "db pc=<addr>"
- use the '&' to apply an optionnal mask before doing the comparison
The syntax I was thinking about would allow things like :
pc=$1200 : stop when pc=$1200 (before executing the instruction at $1200)
(a0)=32 : stop when the 32 bits pointed by a0 contain the value 32
($ff820a).b = 2 : stop when the byte stored at address $ff820a=2
($ff8260).b & 3 = 1 : stop when the byte stored at address $ff8260, masked
with a binary "and 3" is 1 -> useful to stop when the resolution is
changed, as only bit 0 and 1 of $ff8260 have a meaning on STF/E.
(a1).w = d1 : stop if the 16 bits pointed by a0 are the same as the 16
lower bits of register d0.
This means we would have some reserved word (=regs)that should be
interpreted as 68000 registers, not as some hexa values : a0 to a7, d0 to
d7, pc, ssp, ..., + more for dsp reg.
A breakpoint "unit" would be :
<value> <comparison> <value>
where <value> could be
| (regs)[.size] [&mask]
Then as you suggest, we should be able to "chain" many units with "and" or
"or" to have a more complex condition for the final breakpoint.
Based on the skeleton code you wrote, I think this could be quite feasible
with a little extra work, and would give a very good flexibility.
Then we should be able to have many breakpoints at the same time, each
breakpoint being the combination of one or more condition.
This means we would have a linked list (or a limited size array, that's
easier to handle) of max N breakpoints, each entry would contain a
structure describing one breakpoint (a breakpoint could be a combination
of many conditions with "or" or "and")
If breakpoint mode is set during execution, then we should scan the N
entries of the main breakpoints table to see if a breakpoint matches. As
soon as a match is found, we call DebugUI.
More information about the hatari-devel