[hatari-devel] Debugger improvements

Laurent Sallafranque laurent.sallafranque at free.fr
Sat Feb 6 12:59:22 CET 2010


Hello Eero,

I'll test all of this next week, I won't be here today and tomorrow.

Would it be possible to have this kind of command :

d pc
dd pc

This is easier to write than d $e1563 for example ;)
(I'm sometimes lazy)

Regards

Laurent




Eero Tamminen a écrit :
> 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. :-)
>>     
> _______________________________________________
> hatari-devel mailing list
> hatari-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/hatari-devel
>
>
>   




More information about the hatari-devel mailing list