Now this function uses SB API instead of HandleCommand.
So with CMICmnLLDBDebuggerHandleEvents::HandleProcessEventStateSuspended() it will report a bunch of text back through the MI interface with this each time? Why would it do that? I would assume that the MI interface would handle this programmatically?
As long as the process remains stopped you are ok.
If you look at what this patch is doing, it ends sending text to stdout at the end. So it seems like this function's sole purpose is to report the process status after stop to STDOUT. Seeing as this is a machine interface (MI) to a debugger, I was wondering why it would do this.
It seems that it's impossible to get HandleProcessEventStateSuspended called on Linux, so I've copied code of this patch into
HandleProcessEventStateStopped to check new output.
~"Process 17065 stopped\n* thread #1, name = 'bash', stop reason = breakpoint 1.1\n frame #0: 0x000000000041eed0 bash`main\nbash`main:\n-> 0x41eed0 <+0>: pushq %r15\n 0x41eed2 <+2>: pushq %r14\n 0x41eed4 <+4>: pushq %r13\n 0x41eed6 <+6>: pushq %r12\n"
SBProcess: pid = 17065, state = stopped, threads = 1, executable = bash thread #1: tid = 17065, 0x000000000041eed0 bash`main, name = 'bash', stop reason = breakpoint 1.1
Of course, it will be state = suspended in a "real life".
AFAIK, all lldb-mi commands print their final result records to stdout. All lldb-mi commands are inherited from CMICmdInvoker which has CmdExecuteFinished(...) method that is invoked when a command is finished, this method then call CmdToStdout(...) method which prints command's result to stdout. So, I guess, it's ok, isn't it?
Hmm.. yeah, this looks more like a side-channel than a proper part of the MI protocol. That said, this is also what the original code was doing, so we can investigate the proper protocol separately.