Re: [hatari-devel] Memory access tracing

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 11/08/2013 02:59, Eero Tamminen wrote:

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

The point of using SPCFLAG_MONITOR_RAM is to optimise the tests when no 
read/write accesses breakpoints are used, only "standard" breakpoints.

Let's consider a function to handle write to RAM :

void	handle_write_16 ( uint32 address , uint16 val)
{
  /* copy val to address */
  ...
}

Now if we change it to :

void	handle_write_16 ( uint32 address , uint16 val)
{
  if ( spcflag & SPCFLAG_DEBUGGER )
    {
      Call_Debugger_Code
    }
  /* copy val to address */
  ...
}

it will work ; but if the user has not defined breakpoints to really 
monitor read/write, it will be a waste of ressource and we will call 
debugger on every read/write, even if no breakpoints are possible. This 
would be a huge slowdown.

That's why I think that to speed up decision, we should have another 
flag SPCFLAG_MONITOR_RAM (or MONITOR_MEMORY or whatever).

When a breakpoint is set and it doesn't involve monitoring read/write 
accesses (as the ones available today), we only set SPCFLAG_DEBUGGER .

When a breakpoint is set involving accesses, we set SPCFLAG_DEBUGGER | 
SPCFLAG_MONITOR_RAM.

This way, there's a first dichotomy in handle_write_16 and the 
breakpoint analysis is ran only if there're really some memory accesses 
to check. Else, we get the usual behaviour where spcflag is only tested 
at the end of the current instruction.

void	handle_write_16 ( uint32 address , uint16 val)
{
  if ( spcflag & SPCFLAG_MONITOR_RAM )
    {
      Call_Debugger_Code
    }
  /* copy val to address */
  ...
}


Nicolas