Re: [hatari-devel] A question about the debugger

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On tiistai 03 syyskuu 2013, Roger Burrows wrote:
> On 3 Sep 2013 at 13:19, Roger Burrows wrote:
> > Is it possible to trace reads & writes to the ACSI/floppy interface
> > ($ffff8604/06)?  I am fixing the ACSI code in EmuTOS and would like to
> > see exactly what is being written to those addresses.

If you're interested about all accesses to them, you need to trace
all IO-accesses with:
	--trace io_all

And then just grep stuff that's interesting for you from the Hatari
output.


If it's enough to know just about the register *changes*, you can use
tracing breakpoint for those addresses:
	b  ($ffff8604) ! ($ffff8604)  :trace
	b  ($ffff8606) ! ($ffff8606)  :trace

If you want to know what instruction lead to those register changes, use:
	history cpu
	lock history 8

And add ":lock" option to breakpoints, to see last 8 instructions leading
to register change.  If you want to see just new register value, not
all breakpoint verbosity, add ":quiet" option to breakpoint.


Output looks like this:
--------------------------------
> history cpu
History tracking enabled for CPU.
> lock history 8
Locked history output.
> b  ($ffff8604) ! ($ffff8604)  :trace :lock :quiet
....
> b  ($ffff8606) ! ($ffff8606)  :trace :lock :quiet
....
> c
Returning to emulation...
  $ffff8604 = $f40086
$fc1688 : 302d 0a08                            move.w    $a08(a5),d0
$fc168c : 119f 0000                            move.b    (sp)+,(a0,d0.w)
$fc1690 : 4e75                                 rts       
$fc1462 : 302d 0a26                            move.w    $a26(a5),d0
$fc1466 : 48c0                                 ext.l     d0
$fc1468 : 6002                                 bra.s     $fc146c
$fc146c : 2f00                                 move.l    d0,-(sp)
$fc146e : 3cbc 0086                            move.w    #$86,(a6)
Debugger: *CPU breakpoint*
  $ffff8604 = $86
$fc1636 : 51cf fffe                            dbra      d7,$fc1636
$fc1636 : 51cf fffe                            dbra      d7,$fc1636
$fc1636 : 51cf fffe                            dbra      d7,$fc1636
$fc1636 : 51cf fffe                            dbra      d7,$fc1636
$fc163a : 3e1f                                 move.w    (sp)+,d7
$fc163c : 46df                                 move      (sp)+,sr
$fc163e : 4e75                                 rts       
$fc1614 : 33c7 ffff 8604                       move.w    d7,$ffff8604
Debugger: *CPU breakpoint*
  $ffff8606 = $800000
$fc163e : 4e75                                 rts       
$fc147a : 3c3c 0010                            move.w    #$10,d6
$fc147e : 6100 00be                            bsr       $fc153e
$fc153e : 3029 0002                            move.w    2(a1),d0
$fc1542 : c03c 0003                            and.b     #3,d0
$fc1546 : 8c00                                 or.b      d0,d6
$fc1548 : 2e3c 0004 0000                       move.l    #$40000,d7
$fc154e : 3cbc 0080                            move.w    #$80,(a6)
Debugger: *CPU breakpoint*
  $ffff8604 = $80
--------------------------------


> > The new code
> > works as long as GCC optimisation is turned off, so I need to see
> > what's different when optimisation is enabled.
> 
> Just a followup in case there is any confusion:
> 1. the existing EmuTOS code works OK on Hatari, but not on real hardware,
> so I'm fixing it.
> 2. with GCC optimisation off, the new EmuTOS code works fine on real
> hardware. 3. with GCC optimisation ON, the new EmuTOS code gets a
> timeout error when sending a read command to read certain specific
> sector numbers.
> 4. there are no problems reading the same sectors with TOS.
> 
> So I'd like to debug the optimised code on Hatari ...

Even more info you get by loading EmuTOS symbols and tracing also
"cpu_symbols".


	- Eero