You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An initial prototype can be slow, as long as the instrumentation is disabled by default.
I think several optimizations will eventually be necessary.
We cannot afford a clean-call all the way out to Python for every memory access. At a minimum, filtering needs to take place in pyda_core -- ideally inline. Users likely only care about a range (or: several ranges) of memory addresses, and our instrumentation should check the address (using in-line instrumentation) so it only performs a clean-call at all if the access is within one of these regions.
One potential optimization is to make watched accesses cause a fault (i.e. by changing page protections), and then handling the fault by selectively inserting instrumentation into the block where the fault occurred
The text was updated successfully, but these errors were encountered:
We can instrument memory accesses, following the example of https://github.com/DynamoRIO/dynamorio/blob/master/api/samples/memtrace_simple.c.
An initial prototype can be slow, as long as the instrumentation is disabled by default.
I think several optimizations will eventually be necessary.
The text was updated successfully, but these errors were encountered: