Re: [hatari-devel] Memory access tracing

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 11/08/2013 17:31, Eero Tamminen wrote:
> Only debugger code that needs to be run in these cases is setting
> some variables.  In minimal case it's:
> 	MemWriteAddress = addr;
>
> Which shouldn't be that much slower than doing an if instead:
> 	if (spcflag & SPCFLAG_MONITOR_RAM)
> 		MemWriteAddress = addr;
>
>
> Once I have the patch, it can be measured, but if it turns to have
> any noticeable impact, I'd rather put it behing an ifdef than if  [1].

If you just want to set "MemWriteAddress = addr" in each memory write 
handler, then I agree it's faster to do it directly than do check 
spcflag first.

But as I explained earlier, I think this approach is partially not 
complete, as it defer the analysis at the end of the instruction in a 
cumulative way.

Consider  you want to monitor addresses $1000, $1004, $1008 ; a movem at 
$1000 will report the last MemWriteAddress=$1008, but chronologicaly, 
you would want $1000 to be reported.
As you say, you can have a look at the disassembly to see what happened, 
but doing that won't always work and give a clear view.

When your code is crashing at a point where you really don't understand 
what is happening and which instruction (or dma) is writing to a memory 
location, I think precision is required. That's why I'm not sure storing 
MemWriteAddress is enough, because it's not 100% accurate.

I'd rather see a complete solution where each memory access can trigger 
the debugger, as I described with SPCFLAG_MONITOR_RAM, and we don't have 
to change it anymore in the future.


> What kind of syntax you suggest to debugger for enabling memory
> monitoring?

I haven't think of it yet.


> Regardless of how the CPU instruction memory access monitoring will be done,
> it has minuscule performance impact compared to that. :-)

With "MemWriteAddress", there will be an impact, could be minimal or not 
depending on what you're usually debugging.

But with a possible call to debugger() on each access as I suggest, I 
think it's important to have a separate SPCFLAG_MONITOR_RAM flag.

It won't have minimal impact if the user doesn't have DSP breakpoints 
and only wants to debug some STF stuffs. I agree that in worst case, 
where debugger has already many triggering conditions, adding memory 
access monitoring won't change a lot of things.

But the case that should have minimal impact wrt memory moniotring, is 
the one where for example you just want to have a 68000 breakpoint on a 
specific PC value.

This is a very usual and simple breakpoint case, you don't want it to be 
called on each memory access, only after the instruction.

I mean, don't even call debugger() during the memory access if "spcflag 
& SPCFLAG_DEBUGGER" is set. We must use the additionnal 
SPCFLAG_MONITOR_RAM to "stop" the memory access monitoring processing as 
soon as possible in the handlers for each kind of memory access.

Nicolas