Re: [hatari-devel] Intercepting memory accesses

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 27/01/2017 à 23:29, Eero Tamminen a écrit :
> Hi,
>
> I'd like to bring up again debugger support for
> intercepting memory accesses.  STeem debugger supports
> that, so it can't be too expensive performance-wise...
>
>
> Nicolas, didn't you have some patches for that?
>
> I'd like to try them out to see what's their performance
> impact (when interception is not enabled).  If it's
> too heavy to have that enabled in default builds, at
> least have it as a separate build option, which would
> enable also additional debugger features.
>
>
> Reason for looking into this is that Vincent asked for
> support of specifying READ|WRITE|EXEC access rights for
> specified memory areas (e.g. through NatFeats), so that
> Hatari would invoke debugger if some instruction violates
> those access restrictions.
>
> This could be used to (for example) protect & detect
> programs (games) trying to overwrite OS in-RAM structures,
> and detecting over & underflows for whole stack or
> individual stack elements (in OS and programs).

Hi

I had some hardcoded cases for some specific program I wanted to trace, 
but nothing really clean, it was mainly some "if addr==xxx" added in the 
memory access functions.

Considering the cpu emulation already does a lot of stuff, I don't think 
adding a check for some memory accesses breakpoint would add that much 
overhead and would be really noticeable (what's more important is that 
emulation speed is not degraded when there's no breakpoint).

I might have a look at this somedays later, I need to finish some other 
work regarding cpu at the moment.

Nicolas