Re: [hatari-devel] Memory access tracing |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
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