[hatari-devel] Steem debugger features not in Hatari debugger

[Eero Tamminen]

Hi,

On tiistai 07 kesäkuu 2011, Nicolas Pomarède wrote:
>> [1] One more reason for this is that I assume there could be quit
>> a lot of these breakpoints (especially if they're easy to add from an
>> UI), whereas number of conditional breakpoints is quite limited and
>> they're slower to check.  Address breakpoints can be binary searched
>> from an array.
> 
> Yes, there could be 2 categories of breakpoints. Even in current CLI
> debugger this could be better for performance to have "simple" PC
> breakpoints in one list, and more complex breakpoint in a 2nd list.

After reading the MonST manual again, I noticed that its conditional
breakpoints are actually all tied to a PC address.

A specific expression is evaluated only on given PC address,
which makes them:
- such that you can show them in disassembly at right place
- faster

As the debugger already has expression evaluation, run-time evaluated
expression could be easily added to PC breakpoints too, maybe signified
with "?" (MonST separates breakpoint address & condition with "?").


In MonST the break happens if expression result is non-zero (= true),
but I think in our case it would be better to break when the expression
result is zero, like in:
	a $cdef  ?a0 - bss?
(when pc=$cdef, break if a0 points to program bss)

But I wonder should these expression be able to contain conditions too:
	a $cdef ? a0=bss && a1!bss+2 ?
?

Then I think conditional breakpoints would need to be re-designed around
/ moved to address breakpoint code so that e.g. breakpoint for pc=0
would signify the special case where condition should be evaluated for
every instruction.


	- Eero