Won't this slightly change the behaviour on hardware single-step
archs? Before, we'd always tell the target to resume a single-thread
(keeping the others stopped, on target that support scheduler locking);
with this change, I think you'll tell the target to resume all
threads.
Hmmm, yes, you're probably right. I we were to set trap_expected,
then we would only step that one thread, but would that be cheating?
be too ugly? Hmmm, maybe not OK, it can have other side
effects, like tripping on this...
if (ecs->event_thread->stop_signal == TARGET_SIGNAL_TRAP
&& ecs->event_thread->trap_expected
&& gdbarch_single_step_through_delay_p (current_gdbarch)
&& currently_stepping (ecs->event_thread))
I guess we might, if we hit the watchpoint while stepping. But then,
trap_expected would have already been set, and thus we'd be OK without
setting it anyways.
Regardless, I think this just shows that calling resume like this is
just too ugly. Perhaps a better approach would be to extract out the
part that handles software_single_step out of resume and have both
resume & handle_inferior_event call that new function?