Open akihikodaki opened 4 years ago
Just out of curiosity, which exact event(s) were we missing?
TargetSignaled
is a stop event but was not listened by sdb.
Hmm. It seems to me that we would want to let the user know if such an event occurred, similar to how we say Inferior process suspended
, Inferior process interrupted
, etc. So I would suggest attaching an event to TargetSignaled
(assuming that's exposed in the API) like so:
_session.TargetSignaled += (sender, e) =>
{
// maybe log the signal name/id as well, if available through the API on `e`?
Log.Notice("Inferior process '{0}' ('{1}') signaled",
ActiveProcess.Id, StringizeTarget());
};
Hmm. It seems to me that we would want to let the user know if such an event occurred, similar to how we say
Inferior process suspended
,Inferior process interrupted
, etc. So I would suggest attaching an event toTargetSignaled
(assuming that's exposed in the API) like so:_session.TargetSignaled += (sender, e) => { // maybe log the signal name/id as well, if available through the API on `e`? Log.Notice("Inferior process '{0}' ('{1}') signaled", ActiveProcess.Id, StringizeTarget()); };
I think that would be nice. I suppose it requires another pull request.
The debugger does not listen to some events fired by
SoftDebuggerSession
, and may miss a stop event, which resumes command line processing, and lead to hangup.SoftDebuggerSession.TargetEvent
handles all events and eliminates possibility to introduce a hangup also in the future.