[hatari-devel] register locking in debugger

Eero Tamminen eerot at users.berlios.de
Fri Feb 12 23:06:57 CET 2010


Hi,

On Friday 12 February 2010, npomarede at corp.free.fr wrote:
> Regarding monst, it's possible to lock a register and choose hex dump or
> disasm dump ; this is possible for any register, the fact that it's a
> data or address reg shouldn't limit what kind of dump (as in highly
> optimized code, where all registers are used, it's often possible to
> store address in data reg for example).

The commited syntax is:
	lock regaddr <disasm|memdump> <register>

As only Rx registers are valid for DSP, one doesn't need to specify
otherwise whether it's for CPU or DSP.


> I don't know what should be shown ; problem is that if you lock several
> registers it will become quite a mess on screen.  My opinion is that some
> extra windows could be used to display locked registers or locked i/o
> spaces (like showing video regs, blitter regs, ...), with only a single
> text terminal as output, I'm afraid more advanced debugging functions
> (those that can display a lot of data) will prove to be hard to use in an
> efficient way.

What I've implemented supports locking only single thing at the time
(to be shown when entering the debugger).

If you want to know what multiple registers point at, I think it's better
to improve the original "registers" command so that besides register
values, it shows also few bytes from where they point at.

Maybe like this:
-------
D0: 00000000: 602e 0404 00e0 0030 00e0 BT .B #$0000002e == 00000030 (TRUE)
...
A7: 0000886c: 00e0 0766 0000 0000 0000 ILLEGAL.L

USP=00000000 ISP=0000886c MSP=00000000 VBR=00000000
T=00 S=1 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=3
FP0: 0 FP1: 0 FP2: 0 FP3: 0
FP4: 0 FP5: 0 FP6: 0 FP7: 0
N=0 Z=0 I=0 NAN=0
prefetch 31fc008f
00e01cb0: b290 62fc 31fc 008f 8606 CMP.L (A0),D1
next PC: 00e01cb2
-------


> Perhaps something that should be taken care of in the python ui for
> instance.

Transferring the information between that and Hatari is a bit problematic,
there's a strange delay between sending commands to Hatari and getting
the results.

I was thinking that I could try writing the debugger GUI at some point in
a compiled language to see whether than delay disappears, maybe using
C++ / Qt.  But that probably won't happen this year (I've never used Qt,
this might be an OK project to try it :-)).

Another possibility is that the issue is at kernel level, maybe it does some
buffering aimed at higher throughput instead of low latency...


> > And should this kind of setting be saved to memory state file or
> > configuration file?
>
> Maybe this should be saved to a specific hatari_debug.cfg file instead of
> using the memory state ; I think it's better if the memory state file
> changes only (or mostly) when the emulated machine changes, not when the
> ui/debugging interface change.

Hm. I probably should add a separate config file section for the debugger.


	- Eero



More information about the hatari-devel mailing list