[hatari-devel] Debugger improvements

Eero Tamminen eerot at users.berlios.de
Sat Feb 6 00:34:49 CET 2010


Hi,

FYI: I just commited (lightly tested) symbols support for conditional
breakpoints.  This allows setting breakpoints on data symbols (and
their value changes) whereas address breakpoints supported only
code symbols.

Next to come will be symbol support for cpu memdump and
dsp disasm & memdump (+ counter support for dsp address
breakpoints).


Btw. The feature commented below will allow "run until <condition>"
that was one of the Monst things missing from Hatari debugger.

One can use:
	b <some condition> once
	c
to run until some condition happens, the breakpoint is automatically
removed after that.


Btw. I was wondering about the data change breakpoint mentioned below.
Currently with "!" comparison, it tracks changes constantly by updating
the value which causes a breakpoint.  Should there be also something like:
	pc > pc
Which would take the current value of PC and break when PC register goes
over value (would really make sense only with "once" keyword)?

It's a bit handier than first using "regs" to check register value or
"memdump" to check a memory address value and then typing that
value to the breakpoint expression.

(The PC reg example above would be handy for getting out of looping code.)



	- Eero

On Sunday 31 January 2010, Eero Tamminen wrote:
> > There are quite many different values it writes there:
> >       $007f
> >       $00bf
>
> ...
>
> I added IMHO nice new feature to conditional breakconds to find out these
> kind of issues.  Now, to see when a value of a specific memory address
> changes, just give exactly the same expression for that address value on
> both sides of the condition comparison.  To just see the value changes
> without breaking, add "trace" keyword to the end of the whole expression.
>
> Like this:
> -----------
>
> > b ($ffff9202).w ! ($ffff9202).w trace
>
> CPU condition breakpoint 1 with 1 condition(s) added.
> -> Track condition(s), show value(s) when matched.
> -> Trace, show hits, but don't break.
> -----------
>
> Tracing is also shown in the conditional breakpoints list:
> -----------
>
> > b
>
> 1 conditional CPU breakpoints:
>   1: ( $ffff9202 ) . w ! ( $ffff9202 ) . w, traced
> -----------
>
> The tracked breakpoint can have also additional conditions to make sure
> that it's not triggered too often.
>
> And naturally you can monitor changes happening to multiple addresses at
> the same time just by adding more breakpoint with this kind of
> conditions.
>
>
> The trace output of the example breakpoint looks like this with
> Moonspeader: -----------
> 1. breakpoint conditions matched 1664 times.
>   $ffff9202 = $df
> 1. breakpoint conditions matched 1665 times.
>   $ffff9202 = $ffff
> 1. breakpoint conditions matched 1666 times.
>   $ffff9202 = $fb
> 1. breakpoint conditions matched 1667 times.
>   $ffff9202 = $ffff
> 1. breakpoint conditions matched 1668 times.
>   $ffff9202 = $bf
> -----------
>
> I hope you'll like it. :-)



More information about the hatari-devel mailing list