Debugger with GDB: how to add a write memory breakpoint that triggers even if the value hasn't changed as a result of a write?

[aldelaro5]

This is a problem I am having with GDB itself, but I am stumped and I imagine this might not necessarily an uncommon case so I might as well ask here.

I am trying to reverse engineer a GBA game using mgba's GDB stub (a GBA console emulator). I am trying to set a memory breakpoint on write ONLY (read/write is not what I want) and the problem I have is GDB only stops the inferior if the write caused a change with the value (if the case it hasn't changed, it will ignore it and tell the inferior to continue).

There are 2 problems with this that would affect not only mgba, but basically every other console emulator which has a GDB stub:

1: Most of the time, I actually care about ANY write to an address and maybe sometime I only care about changes so already, this seems like a huge limitation.
2: mgba and most other emulators of this kind has a feature to save and restore the state of the emulation (memory, CPU, etc...) so what can happen is the watchpoint would trigger properly, then I load a state and now it wouldn't trigger again because GDB thinks the value hasn't changed since the last time it broke, but GDB isn't aware that the memory has changed on the state load. I couldn't find a way via the stub to inform GDB of that. It's possible to manually solve it by ctrl +c after the load, but it's not ideal.

So my question is simple: how can ghidra, GDB or even the stub allow me to have a write watchpoint that ALWAYS triggers on write even if the value is unchanged? Since it seems to be a limitation of GDB, this is mostly a GDB question, but again, I can't imagine this being uncommon to want in reverse engineering (say you care that something is refreshing the value, it might not change, but you still care that a write occurred).

[d-millar]

@aldelaro5 yeah, the access watchpoint behavior is typically tied directly to the underlying processor architecture. for Intel, this means the bits in the DR7 register, which allow execution, write, read/write, or IO. there are other ways to do this, e.g. using the PEBS registers or modifying page access permissions and trapping on violations, but gdb (and most debugger) do not provide easy access to these features.

[d-millar]

Moved to Discussions from Issues, just in case someone has additional insight.