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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On tiistai 03 syyskuu 2013, Eero Tamminen wrote:
>        b  ($ffff8604) ! ($ffff8604)  :trace
>        b  ($ffff8606) ! ($ffff8606)  :trace

These are word sized registers, so above should check just word:
        b  ($ffff8604).w ! ($ffff8604).w  :trace
        b  ($ffff8606).w ! ($ffff8606).w  :trace

(Without width specifying, Hatari debugger will read long.)


> 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.

I thought the output of this breakpoint was really wierd until I checked
what FDC code does.  Read accesses *modifies* the register.


> On tiistai 03 syyskuu 2013, Roger Burrows wrote:
> > 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.

Roger, have you specified in all relevant variables that they point to
addresses which contents are volatile i.e. that they change outside of
EmuTOS control?

Without that, GCC can assume that what will be read from there afterwards
is what you wrote there.


	- Eero