mirror of https://github.com/pwndbg/pwndbg.git
get_one_instruction: clear "cont" cache on mem/reg changed (#1828)
* get_one_instruction: clear "cont" cache on mem/reg changed Fixes #1818. Note that this makes a substantial change: it changes all caches that are refreshed on `gdb.ContinueEvent` to also be cleared on memory/regs changed. This change is needed so that the `get_one_instruction` function which uses this cache will get its cache cleared when user invokes a command that changes memory or registers. While this may sound as too big change: we are changing the whole "cont" cache to be cleared on two additional events, this should not be an issue. This is because: 1. We should notice it if we start clearing an important cache too often 2. The "cont" cache is currently only used by the `get_one_instruction` at this moment. The 2) also creates a question: when should one use "cont" vs "start" caches? It is not so clear to me right now. * Add test for issue #1818 * Clear caches on MemoryChanged events from gdblib.write Regarding the last part: Interestingly implementing tests here uncovered another bug: the gdblib.memory.write(..) or rather the gdb.selected_inferior().write_memory(...) API used there does not trigger a gdb.MemoryChanged event. As a result, we never cleared certain caches that should have been cleared when the user used that API. I have added two tests here, one changes the instructions at $RIP to nops via gdblib.memory.write(..) and another via executing the patch $rip nop;nop;nop;nop;nop command. As a result, we test both scenarios: 1) when we depend on memory changed event being fired via GDB to clear caches; and 2) when we depend on gdblib.memory.write(..) to clear the caches. This PR also makes a fix to the gdblib.memory.write(..) to actually clear caches that depend on (or rather: are hooked to in order to be cleared) memory changed events.pull/1829/head
parent
6271157090
commit
1cb2be2f35
Loading…
Reference in new issue