deferred_stop_reason takes a ThreadStopReason in single-threaded mode?

[daniel5151]

deferred_stop_reason takes a ThreadStopReason in single-threaded mode?

[bet4it]

You could use into:

let reason = StopReason::DoneStep;
match gdb_inner.deferred_stop_reason(emu, reason.into())? {
    ...
}

[daniel5151]

If you peek under-the-hood of gdbstub, you'll find that singlethread::StopReason gets converted into a multithread::ThreadStopReason with a constant SINGLE_THREAD_TID:

gdbstub/src/gdbstub_impl/ext/base.rs

Lines 782 to 804 in 4344c85

	use crate::target::ext::base::singlethread::StopReason;
	impl<U> From<StopReason<U>> for ThreadStopReason<U> {
	fn from(st_stop_reason: StopReason<U>) -> ThreadStopReason<U> {
	match st_stop_reason {
	StopReason::DoneStep => ThreadStopReason::DoneStep,
	StopReason::GdbInterrupt => ThreadStopReason::GdbInterrupt,
	StopReason::Exited(code) => ThreadStopReason::Exited(code),
	StopReason::Terminated(sig) => ThreadStopReason::Terminated(sig),
	StopReason::SwBreak => ThreadStopReason::SwBreak(SINGLE_THREAD_TID),
	StopReason::HwBreak => ThreadStopReason::HwBreak(SINGLE_THREAD_TID),
	StopReason::Watch { kind, addr } => ThreadStopReason::Watch {
	tid: SINGLE_THREAD_TID,
	kind,
	addr,
	},
	StopReason::Signal(sig) => ThreadStopReason::Signal(sig),
	StopReason::ReplayLog(pos) => ThreadStopReason::ReplayLog(pos),
	StopReason::CatchSyscall { number, position } => {
	ThreadStopReason::CatchSyscall { number, position }
	}
	}
	}
	}

It's been a while since I've hacked on this code directly, but IIRC I couldn't think of a great way to parameterize deferred_stop_reason over single/multi-threaded targets, so I took the "cop out" approach of simply using the more specific multithread::ThreadStopReason type.

That said, after reviewing the code with fresh eyes this morning, I suspect that long-term, I'll actually end up removing singlethread::StopReason entirely, and swapping all APIs over to using a single StopReason type which encodes both the TID, and PID of the stopped thread (in anticipation of eventually supporting multi-process debugging as well).

So, to answer your concrete question: yes, I'm aware of this weird aspect of the API, and I'm planning to solve it in one of two ways:

1. updating the documentation to make it very clear how to use the state machine with single-threaded targets
2. making the point moot by removing "singlethread::StopReason" type entirely (along with any requisite doc changes)

[gz]

Great, thanks for clarifying!

[gz]

agreed I didn't see the into() implementation. What was mainly confusing here for me was that in the single-threaded API there was a type from crate::target::ext::base::multithread. But I suppose that Daniels refactoring will probably move this type somewhere more general.

[daniel5151]

This has been fixed in 2eca733 and a24b724