MI Handle events.

Hi lldb-dev,

I’m looking at re-implementing of CMICmnLLDBDebugHandleEvents::HandleProcessEventStateSuspended to get rid of HandleCommand(“process status”) hack and use SB API instead. To check my changes I need to get HandleProcessEventStateSuspended called, so could someone help me with a sequence of lldb-mi commands which will call HandleProcessEventStateSuspended.

Thanks in advance.

Hi lldb-dev,

I'm looking at re-implementing of CMICmnLLDBDebugHandleEvents::HandleProcessEventStateSuspended to get rid of HandleCommand("process status") hack and use SB API instead. To check my changes I need to get HandleProcessEventStateSuspended called, so could someone help me with a sequence of lldb-mi commands which will call HandleProcessEventStateSuspended.

Other than reading through the code and manually tracing a sequence where this function gets called, one simple trick you can try is to put an assert(false) into HandleProcessEventStateSuspended, run the testsuite (or perform an lldb-mi debug session) and look for a testacase that triggers the new assertion.

-- adrian

The eStateSuspended state is used for threads (you can set it via
SBThread::Suspend/Resume). It controls whether a "continue" operation
on the process will run the thread or not.

I am not sure if you can ever see that state on the process itself.

I’ve tried to put an assert into HandleProcessEventStateSuspended, but there wasn’t a testcase triggering it. So, my question is still actual, any help will be really appreciate.

пн, 16 июл. 2018 г. в 13:56, Pavel Labath <labath@google.com>:

Have you tried my other suggestion; doing an actual debug session with an lldb-mi client (emacs/vim/vs code/eclipse)? Of that doesn’t work, I’m afraid you may have to do some detective work here to figure out how to add test coverage for this code path. I ssume that you already tried to create a synthetic test that suspends a process and then queries the status through the MI interface?

– adrian

Well, judging by this snippet