Here is what I got from gdb-remote packet log: (gdb) lldb-mi < 1> send packet: + lldb-mi history[1] tid=0x784a < 1> send packet: + lldb-mi < 19> send packet: $QStartNoAckMode#b0 lldb-mi < 1> read packet: + lldb-mi < 6> read packet: $OK#9a lldb-mi < 1> send packet: + lldb-mi < 41> send packet: $qSupported:xmlRegisters=i386,arm,mips#12 lldb-mi < 124> read packet: $PacketSize=20000;QStartNoAckMode+;QThreadSuffixSupported+;QListThreadsInStopReply+;qEcho+;QPassSignals+;qXfer:auxv:read+#be lldb-mi < 26> send packet: $QThreadSuffixSupported#e4 lldb-mi < 6> read packet: $OK#9a lldb-mi < 27> send packet: $QListThreadsInStopReply#21 lldb-mi < 6> read packet: $OK#9a lldb-mi < 13> send packet: $qHostInfo#9b lldb-mi < 11> send packet: $qEcho:1#5b
Could somebody help me with understanding of what is happening here? On Wed, Aug 15, 2018 at 12:26 AM <[email protected]> wrote: > 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 <[email protected]> *On Behalf Of *????????? > ??????? via lldb-dev > *Sent:* Tuesday, August 14, 2018 4:14 PM > *To:* Adrian Prantl <[email protected]> > *Cc:* LLDB <[email protected]> > *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 <[email protected]> wrote: > > > > > > On Aug 14, 2018, at 12:11 PM, Александр Поляков <[email protected]> > 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 <[email protected]> wrote: > > > > > > On Aug 13, 2018, at 4:19 PM, Александр Поляков <[email protected]> > 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 > -- Alexander
_______________________________________________ lldb-dev mailing list [email protected] http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
