Re: [hatari-devel] Memory access tracing (was: Hatari debugger question)

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On sunnuntai 11 elokuu 2013, Nicolas Pomarède wrote:
> 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.

I think cases like this should be rare enough that such false positives
don't matter.  If it triggers a breakpoint, one can always check
from disassembly & regs what actually happens.  It just needs to be
documented.


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

I think it would be usually used so that one gives it single address,
and if that doesn't catch it (due to move* etc), then one tries it
with larger range.

Bugs one hunts with this kind of facility, will hopefully be reproducible..


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

The point of putting the address(es) in variable(s) is that you can
set different kind of breakpoints on them.  That part isn't optional.

checking SPCFLAG_MONITOR_RAM would lose most of the debugger advantages
and it's redundant with the variables.


> 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

2 variables would cover this.

>   - the direction : read, write or both
>   - the component doing the access, as a bitmask (cpu, dma fdc, dma
> sound, blitter, dma dsp, ...)

In total 4 variables, of which the last one would need to be set elsewhere.


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

You need to change also stMemory.[ch], as some memory accesses
are done through those.  For example FDC and HDC IO seems to go
through STMemory_SafeCopy().

Misc emulation functions use STMemory_Read* functions, so modifying
that would probably not be a good idea though.


I could try experimenting a bit with this.  If I support just memory
writes, and use single variable, I don't think the overhead is that
large.


	- Eero