CMICmdCmdExecRun::Execute has this line:
lldb::SBProcess process = rSessionInfo.GetTarget().Launch(launchInfo, error); That should do the same thing as the “process launch” command, which will launch lldb-server (linux, bsd, etc) or debugserver (mac), connect to it, and send the A packet to tell it to launch the target. Take a look at the gdb-remote packet log. Inject this command: log enable gdb-remote packets if the log has very little in it, try the process log: log enable gdb-remote process From: lldb-dev <lldb-dev-boun...@lists.llvm.org> On Behalf Of ????????? ??????? via lldb-dev Sent: Tuesday, August 14, 2018 4:14 PM To: Adrian Prantl <apra...@apple.com> Cc: LLDB <lldb-dev@lists.llvm.org> Subject: Re: [lldb-dev] Failing LIT-based lldb-mi tests After long-long debugging I found out that lldb-mi can't successfully launch a process since sometimes it isn't connected with something(I don't know what is it). I found out that it fails after `if (IsConnected())` from `GDBRemoteCommunication::SendPacketNoLock(llvm::StringRef payload)`. Do you have any thoughts about this? On Tue, Aug 14, 2018 at 10:35 PM Adrian Prantl <apra...@apple.com <mailto:apra...@apple.com> > wrote: On Aug 14, 2018, at 12:11 PM, Александр Поляков <polyakov....@gmail.com <mailto:polyakov....@gmail.com> > wrote: It seems that the real problem is that sometimes lldb-mi can't launch a process: build/bin/lldb-mi --synchronous a.out < llvm/tools/lldb/lit/tools/lldb-mi/exec/exec-step-instruction.test (gdb) -file-exec-and-symbols "a.out" ^done (gdb) ^done (gdb) =library-loaded,id="/home/alexander/workspace/gsoc/a.out",target-name="/home/alexander/workspace/gsoc/a.out",host-name="/home/alexander/workspace/gsoc/a.out",symbols-loaded="0",loaded_addr="-",size="0" ^done (gdb) ^done (gdb) ^done (gdb) ^done (gdb) ^done (gdb) ^done (gdb) ^done (gdb) ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00000000004004df",func="main",file="main.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/main.c",line="6",times="0",original-location="main"} (gdb) =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00000000004004df",func="main",file="main.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/main.c",line="6",times="0",original-location="main"} (gdb) ^done (gdb) ^error,msg="process launch failed: 'A' packet returned an error: -1" Do you think you might be able to improve the error message here and get at the underlying failure? -- adrian (gdb) ^done (gdb) ^done (gdb) ^error,msg="Command 'exec-step-instruction'. Thread ID invalid" (gdb) ^done (gdb) ^done (gdb) ^error,msg="Command 'exec-next-instruction'. Thread ID invalid" (gdb) ^done (gdb) ^done (gdb) ^error,msg="this SBThread object is invalid" (gdb) ^done (gdb) ^done (gdb) ^done (gdb) exec-run executes fine in synchronous mode(the only bad thing here is that lldb-mi doesn't react to any external events like SIGSTOP - ctrl+C, while lldb does). All previous logs were made in asynchronous mode and are wrong. On Tue, Aug 14, 2018 at 2:36 AM Adrian Prantl <apra...@apple.com <mailto:apra...@apple.com> > wrote: On Aug 13, 2018, at 4:19 PM, Александр Поляков <polyakov....@gmail.com <mailto:polyakov....@gmail.com> > wrote: Yes, I do, I'm able to pass any command to lldb-mi before the breakpoint is hit. I guess that making exec-run to block the control until the process stops might be the solution we are looking for. Right. I believe that it should (in synchronous mode) behave like "run" in the normal lldb command interpreter and block until the process has stopped. You could look at differences in the implementation of -exec-run and "run" in the command interpreter first. -- adrian -- Alexander -- Alexander
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
