[lldb-dev] Failing LIT-based lldb-mi tests

[via lldb-dev]

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-bounces at lists.llvm.org> On Behalf Of ????????? ??????? via lldb-dev
Sent: Tuesday, August 14, 2018 4:14 PM
To: Adrian Prantl <aprantl at apple.com>
Cc: LLDB <lldb-dev at 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 <aprantl at apple.com <mailto:aprantl at apple.com> > wrote:

 





On Aug 14, 2018, at 12:11 PM, Александр Поляков <polyakov.alx at gmail.com <mailto:polyakov.alx at 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 <aprantl at apple.com <mailto:aprantl at apple.com> > wrote:

 





On Aug 13, 2018, at 4:19 PM, Александр Поляков <polyakov.alx at gmail.com <mailto:polyakov.alx at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180814/4a21fd03/attachment-0001.html>