Well, judging by this snippet
=====
tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp- case lldb::eStateStopped:
tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp- pEventType =
"eStateStopped";
tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp- bOk =
HandleProcessEventStateStopped(vEvent, bShouldB
rk);
tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp- if (bShouldBrk)
tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp- break;
tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp- LLVM_FALLTHROUGH;
tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp- case lldb::eStateCrashed:
tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp- case lldb::eStateSuspended:
tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp- pEventType =
"eStateSuspended";
tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp: bOk =
HandleProcessEventStateSuspended(vEvent);
tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp- break;
=====
it looks like HandleProcessEventStateSuspended can be called in three cases:
1) HandleProcessEventStateStopped sets bShouldBrk to false
2) we get an eStateSuspended event
3) we get an eStateCrashed event
As I said earlier I don't believe (2) can ever happen. I haven't
looked at what can cause (1), but I am sure you can get (3) on a
Mac(*) if your process does a null pointer dereference or a similar
"crashing" action. Is there any test like that in the lldb-mi test
suite?
(*) On linux we just report this as a regular eStateStopped event with
stop_reason = SIGSEGV.
On Mon, 23 Jul 2018 at 09:38, Adrian Prantl <apra...@apple.com> wrote:
>
> 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
>
> On Jul 19, 2018, at 10:14 PM, Александр Поляков <polyakov....@gmail.com>
> wrote:
>
> 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 <lab...@google.com>:
>>
>> 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.
>>
>>
>> On Sat, 14 Jul 2018 at 15:39, Adrian Prantl via lldb-dev
>> <lldb-dev@lists.llvm.org> wrote:
>> >
>> >
>> >
>> > > On Jul 13, 2018, at 10:59 PM, Александр Поляков <polyakov....@gmail.com>
>> > > wrote:
>> > >
>> > > 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
>> >
>> > >
>> > > Thanks in advance.
>> > >
>> > > --
>> > > Alexander
>> >
>> > _______________________________________________
>> > lldb-dev mailing list
>> > lldb-dev@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
> --
> Alexander
>
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
