Re: [hatari-devel] Hatari debugger question

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 11/08/2013 01:22, Eero Tamminen wrote:

> How much of a problem that would be in practice?
>
> I think most of the cases for this would be about instructions modifying
> single memory address, and ones modifying more could still be caught by
> checking larger range for changes:
> 	b LastMemWrite > foobar-14  &&  LastMemWrite < foobar+14
>
> That would definitely be better than nothing.

A range could solve some cases, but not all of them. For example, it 
would not work with movep, which access 1 byte every 2 bytes, so having 
LastMemWrite in the range doesn't mean the condition was met.

Also, having the LastMem address is not enough, we need to specify if 
the address should be monitored for byte, word or long accesses (or the 
3 of them). So here again a movem might access a range of 6 words, but 
if we want to monitor only byte accesses we need more info.

Then, the blitter can access very big range, with not all bytes being 
consecutive ; and from some emulation issues I had to debug, being able 
to trigger debugger on blitter accesses is needed too.

Also, what is a range in current code ? We don't have this notion yet, 
each time a cpu instruction is executed, we don't store the 1st and last 
byte addresses accessed. So we would need to store them on *each* memory 
access, doing so would have an overhead similar to testing "spcflag & 
SPCFLAG_MONITOR_RAM" on each memory access.

And we would need to add this range notion to the blitter, or the dma 
fdc, ...

So, IMO the best approach with minimum/centralized changes is to modify 
the memory access functions to do the 'if' and not add some code to 
update a range in all other HW components (beside CPU) that could access 
memory.

A complete memory breakpoint method should have 4 parameters :
 - the address
 - the size B/W/L
 - the direction : read, write or both
 - the component doing the access, as a bitmask (cpu, dma fdc, dma 
sound, blitter, dma dsp, ...)

Until more complex issues involving ram timings for falcon or more 
accurate MMU/68030+ are not solved, I don't think it's worth 
implementing memory accesses breakpoint, even a more limited version of 
it. Underlying code is not complete enough.

For (rare) cases where it's really needed, modifying cpu/memory.c to 
call the debugger for hardcoded addresses seems a possible solution (I 
used it several time to track some ram accesses).

Nicolas