Re: [hatari-devel] Hatari debugger question

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On sunnuntai 11 elokuu 2013, Nicolas Pomarède wrote:
> On 10/08/2013 19:18, Eero Tamminen wrote:
> > That debugging functionality overhead (SPCFLAG_DEBUGGER bit check on
> > every instruction) is already there, and wouldn't change.
> > 
> > Only additional overhead would be storing the memory access address to
> > internal Hatari variable in all the relevant places of the CPU
> > emulation.
> 
> Problem is that some instruction can do several memory access in one go
> ; consider a movem for example that would read 7 words. Maybe only the
> second word need to be monitored for read access. But in the current
> debugger's flag handling, the debugger is evaluated only once *after*
> the end of the current cpu instruction.

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.


> As you can see, it wouldn't work with current implementation, because it
> would require to store a list of all memory accesses made by an
> instruction and check this list at the end of the current cpu
> instruction when evaluating SPCFLAG_DEBUGGER.

Isn't it so that single instruction can modify only successive memory
addresses?

In that case, it would be enough to have two variables instead of one,
for the start and end of the modified memory range, if one really wants
to know the exact range of instruction's writes (or reads).


> Even so, it wouldn't work if you want to monitor blitter's accesses to
> ram, because blitter doesn't evaluate SPCFLAG_DEBUGGER.

It wouldn't need to evaluate that, just update the variable telling
what was the last modified address (range).


> So, the only solution is to add in every .B/.W/.L memory access
> something like :
> 
> if ( spcflag & SPCFLAG_MONITOR_RAM)
> {
>   ... call debugger functions
> }
> 
> This means spcflag & SPCFLAG_MONITOR_RAM needs to be evaluated in every
> memory access, so that will be a new overhead.

Nope.  Only thing needed is updating one (or two) variables, telling
what address (range) was written (or read).

Initially it could support just telling about writes.


	- Eero