Handle hitting a recording extent boundary as a normal trap-caused stop
Commit Message
Because that's what it is.
This enables reporting of a breakpoint hitting on the first replayable
instruction when reverse-stepping to the beginning of recorded history.
---
gdb/infrun.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
Comments
Raised a related bugticket
https://sourceware.org/bugzilla/show_bug.cgi?id=24073 (Breakpoint on the
first insn of recorded history is not reported in replay).
>>>>> "Andrey" == Andrey Utkin <autkin@undo.io> writes:
Andrey> Because that's what it is.
Andrey> This enables reporting of a breakpoint hitting on the first replayable
Andrey> instruction when reverse-stepping to the beginning of recorded history.
Hi. Thanks for the patch.
See the contribution checklist for some info on how to submit a patch:
https://sourceware.org/gdb/wiki/ContributionChecklist
This one is missing a ChangeLog and perhaps a test case, assuming the
latter is reasonably possible to write.
Tom
@@ -5212,11 +5212,12 @@ Cannot fill $_exitsignal with the correct signal number.\n"));
ecs->event_thread->suspend.stop_pc
= regcache_read_pc (get_thread_regcache (inferior_thread ()));
- if (handle_stop_requested (ecs))
- return;
-
gdb::observers::no_history.notify ();
- stop_waiting (ecs);
+
+ // The end of history is always a stop after a stepping/running op
+ ecs->ws.kind = TARGET_WAITKIND_STOPPED;
+ ecs->ws.value.sig = GDB_SIGNAL_TRAP;
+ handle_signal_stop (ecs);
return;
}
}