In case of MIPS, the watchpoint exception occurred before the associated instruction is executed. Whenever watchpoint is hit , we first preserve the watchpoint index before it is disable and then update the index after enabling it. Thus preserving watchpoint index.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Although this patch fixes the test case in question but in theory EphemeralMode watchpoint enable/disable cycles should be independent of step-over watchpoint enable disable cycle.
On gdb-remote type targets we only update hardware_watch_id when a watchpoint is hit so when we clear hw_watch_id in Watchpoint::SetEnabled (source/Breakpoint/Watchpoint.cpp line 238) then information about last hardware watchpoint id that was hit also gets removed.
To update hardware watchpoint id on gdb-remote targets we ll have to send/recv an extra query packet asking about hardware watchpoint id corresponding to particular watchpoint we just enabled.
One possible solution could be to preserver the hardware watchpint id like way we are preserving stop info in this case. But there no harm in even not clearing watchpoint hardware id on disable rather leave that job for the target to decide if it can update hardware id upon every enable disable or just when watchpoint is hit.
I agree with Pavel, it looks like you're using a side-effect of the Ephemeral mode to preserve something you would be better off preserving explicitly.
This looks fine. Can you add a comment explaining why this is necessary, it isn't obvious right off the bat?
If this is fixing a test case, then just add a comment and this change is fine. If the fix is test-suite neutral, then please add a test case.