Invalidate the register cache after a successful register write - #1173
Conversation
WriteRegister sent the P packet and returned without invalidating the register cache. ReadRegister goes through ReadAllRegisters, which serves m_regCache when it is populated, so every read after a write returned the pre-write value until a step or resume happened to clear it. Editing a register looked like it did nothing, and the debugger kept computing with the old value. Also check the reply is "OK" rather than merely non-empty. RSP answers "E xx" on failure and 'E' is non-zero, so testing the first byte reported failed writes as successful. An empty reply means P is unsupported and still falls through to the G fallback, which already invalidates. The same three lines are duplicated in the Corellium, GDB and esReven adapters, so all three are fixed together. Verified against a live Corellium device: before, a write to x0 landed on the target (a raw RSP probe showed P0= returning OK and p0 returning the new value) while the adapter kept reporting the old one; after, the read-back matches the written value and restoring the original works. Fixes #1172
2ed0c35 to
1cc0e84
Compare
plafosse
left a comment
There was a problem hiding this comment.
This is approved however i'm concerned about it a bit architecturally. Having to remember to call InvalidateCache at a bunch of different locations across all the adapters seems fragile and error prone. Could it be moved into WriteRegister
it is already inside of The reason they all work with a GDB is that they tested against it during development. So if we also wish to be compatible with all of them, we need to replicate what GDB does exactly. That is also why I think we would be circulating back to GDB MI bc that feels like the only way to actually "do exactly as GDB" |
Fixes #1172
WriteRegisterdid not invalidate the register cache after a successfulPwrite, soReadRegisterkept returning the pre-write value until a step or resume cleared it.Editing a register looked like it did nothing.
Also check the reply is
"OK"rather than non-empty: RSP answersE xxon failure and'E'is non-zero, so failed writes were reported as successful. An empty reply meansPis unsupported and still falls through to the
Gfallback.Same three lines in the Corellium, GDB and esReven adapters, so all three are fixed.
Verified on a live Corellium device:
WriteRegister("x0")now reads back what it wrote.