[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
    this register/address"
  - 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]
| (regs)[.size] [&mask]
| constant[.size]
| (constant)[.size]

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.




Nicolas



More information about the hatari-devel mailing list