Re: [lldb-dev] [cfe-dev] stable layout bug for imported record decls.

[Gábor Márton via lldb-dev]

> It might be interesting to consider how this is addressed by the 
> ExternalASTSource interface. There, we have separate "import the lexical 
> contents of this AST node (including populating the lexical declarations list 
> with all members, in the right order)", "import the lookup results for this 
> name in this context (and cache them but don't add them to the list of 
> lexical members)" and "import this specific declaration member (but don't add 
> it to the list of lexical members)" queries. One could imagine doing 
> something similar for the AST importer: when you're performing a minimal 
> import but you want to import a method declaration, don't insert it into the 
> list of lexical members of the enclosing record. Instead, defer doing that 
> until a complete type is required (at that point, you'd need to import all 
> the relevant members anyway, including the base classes and virtual functions 
> in the right order).

Hi Richard, maybe my understanding is not correct, but I believe the
situation is somewhat twisted and reversed.
Seems like LLDB already exercises the ExternalASTSource interface. The
purpose of using it is exactly to load the external lexical contents
of an AST node (as you suggested). However, the load is implemented by
the means of the ASTImporter (in minimal mode). Consider the attached
function call trace:
When the user instructs LLDB to evaluate an expression then LLDB
exercises the parser `clang::ParseAST`, which in turn does a lookup
`clang::DeclContext::lookup`. During the lookup,
`lldb_private::ClangASTSource::FindExternalVisibleDeclsByName` is
called (this function overloads
`ExternalASTSource::FindExternalVisibleDeclsByName`).
And finally, through `lldb_private::ClangASTImporter::CopyType` we end
up in `clang::ASTImporter::Import`.

Gabor

```
#4  0x741a72ed in clang::ASTNodeImporter::ImportDeclParts
(this=this@entry=0x7fff8be0, D=D@entry=0x632038,
DC=@0x7fff8ac8: 0x0,
LexicalDC=@0x7fff8ad0: 0x0, Name=..., ToD=@0x7fff8ad8: 0x0, Loc=...)
at 
/home/gerazo/repos/codechecker_dev_env/CTU/llvm/tools/clang/lib/AST/ASTImporter.cpp:1062
#5  0x741a8d55 in clang::ASTNodeImporter::VisitRecordDecl
(this=0x7fff8be0, D=0x632038)
at 
/home/gerazo/repos/codechecker_dev_env/CTU/llvm/tools/clang/lib/AST/ASTImporter.cpp:2126
#6  0x7419377b in clang::ASTImporter::Import (this=0x70cc90,
FromD=0x632038)
at 
/home/gerazo/repos/codechecker_dev_env/CTU/llvm/tools/clang/lib/AST/ASTImporter.cpp:7054
#7  0x741939f7 in clang::ASTNodeImporter::VisitRecordType
(this=0x7fff8c40, T=)
at 
/home/gerazo/repos/codechecker_dev_env/CTU/llvm/tools/clang/lib/AST/ASTImporter.cpp:851
#8  0x74196f65 in clang::TypeVisitor::Visit (this=this@entry=0x7fff8c40, T=)
at 
/home/gerazo/repos/codechecker_dev_env/CTU/llvm/tools/clang/include/clang/AST/TypeNodes.def:92
#9  0x74197187 in clang::ASTImporter::Import (this=0x70cc90,
FromT=FromT@entry=...)
at 
/home/gerazo/repos/codechecker_dev_env/CTU/llvm/tools/clang/lib/AST/ASTImporter.cpp:6983
#10 0x77351c92 in lldb_private::ClangASTImporter::CopyType
(this=, dst_ast=, src_ast=, type=type@entry=...)
at 
/home/gerazo/repos/codechecker_dev_env/CTU/llvm/tools/lldb/source/Symbol/ClangASTImporter.cpp:61
#11 0x774bdb95 in
lldb_private::ClangASTSource::GuardedCopyType
(this=this@entry=0x611e20, src_type=...)
at 
/home/gerazo/repos/codechecker_dev_env/CTU/llvm/tools/lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp:2040
#12 0x774e9ffe in
lldb_private::ClangExpressionDeclMap::GetVariableValue
(this=this@entry=0x611e20, var=std::shared_ptr (count 6, weak 1)
0x7fffe80020f0,
var_location=..., user_type=user_type@entry=0x7fff8fc0,
parser_type=parser_type@entry=0x7fff8fe0)
at 
/home/gerazo/repos/codechecker_dev_env/CTU/llvm/tools/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp:1627
#13 0x774ea3a7 in
lldb_private::ClangExpressionDeclMap::AddOneVariable
(this=this@entry=0x611e20, context=...,
var=std::shared_ptr (count 6, weak 1) 0x7fffe80020f0, valobj=...,
current_id=current_id@entry=2)
at 
/home/gerazo/repos/codechecker_dev_env/CTU/llvm/tools/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp:1679
#14 0x774ec50b in
lldb_private::ClangExpressionDeclMap::FindExternalVisibleDecls
(this=this@entry=0x611e20, context=..., module_sp=
std::shared_ptr (empty) 0x0, namespace_decl=...,
current_id=current_id@entry=2)
at 
/home/gerazo/repos/codechecker_dev_env/CTU/llvm/tools/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp:1240
#15 0x774ef4ce in
lldb_private::ClangExpressionDeclMap::FindExternalVisibleDecls
(this=0x611e20, context=...)
at 
/home/gerazo/repos/codechecker_dev_env/CTU/llvm/tools/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp:843
#16 0x774c71cc in
lldb_private::ClangASTSource::FindExternalV

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

[Александр Поляков via lldb-dev]

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="0x004004df",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="0x004004df",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"
(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  wrote:

>
>
> On Aug 13, 2018, at 4:19 PM, Александр Поляков 
> 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
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Adrian Prantl via lldb-dev]

> On Aug 14, 2018, at 12:11 PM, Александр Поляков  
> 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="0x004004df",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="0x004004df",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  > wrote:
> 
> 
>> On Aug 13, 2018, at 4:19 PM, Александр Поляков > > 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

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Александр Поляков via lldb-dev]

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  wrote:

>
>
> On Aug 14, 2018, at 12:11 PM, Александр Поляков 
> 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="0x004004df",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="0x004004df",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  wrote:
>
>>
>>
>> On Aug 13, 2018, at 4:19 PM, Александр Поляков 
>> 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

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

[Adrian Prantl via lldb-dev]

> On Aug 14, 2018, at 2:13 PM, Александр Поляков  wrote:
> 
> 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?

You mean that the connection to the debugserver/gdbserver isn't working? How 
does lldb-mi negoiate the port for communicating with the debugger server? Does 
it use the same mechanism as lldb? I'm asking because I remember that a while 
ago I fixed a bug in lldb's random port selection code that could cause two 
concurrently running instances to pick the same port. Does it look like the 
connection never works, or is it being droppped?

+Jim, do you happen to have an idea what this could be a symptom of?

-- adrian
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [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  On Behalf Of ? ??? 
via lldb-dev
Sent: Tuesday, August 14, 2018 4:14 PM
To: Adrian Prantl 
Cc: LLDB 
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 mailto:apra...@apple.com> > wrote:

 





On Aug 14, 2018, at 12:11 PM, Александр Поляков 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="0x004004df",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="0x004004df",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 mailto:apra...@apple.com> > wrote:

 





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

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

[Александр Поляков via lldb-dev]

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=2;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  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  *On Behalf Of *?
> ??? via lldb-dev
> *Sent:* Tuesday, August 14, 2018 4:14 PM
> *To:* Adrian Prantl 
> *Cc:* LLDB 
> *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  wrote:
>
>
>
>
>
> On Aug 14, 2018, at 12:11 PM, Александр Поляков 
> 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="0x004004df",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="0x004004df",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  wrote:
>
>
>
>
>
> On Aug 13, 2018, at 4:19 PM, Александр Поляков 
> 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
>
>
>
>
>
>
> -

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

[Adrian Prantl via lldb-dev]

> On Aug 14, 2018, at 2:43 PM, Александр Поляков  wrote:
> 
> 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=2;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?
> 

Just to clarify: Is this from a session that failed with the symptoms you 
described earlier?
I'm not familiar with the protocol, but the fact that there are send and read 
log entries makes it sound like the communication itself is working.

-- adrian___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Александр Поляков via lldb-dev]

Yes, it is. Here is the gdb-remote process log:

(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
(gdb)
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0040051f",func="main",file="main.c",fullname="/home/alexander/workspace/gsoc/main.c",line="2",times="0",original-location="main"}
(gdb)
=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0040051f",func="main",file="main.c",fullname="/home/alexander/workspace/gsoc/main.c",line="2",times="0",original-location="main"}
(gdb)
^done
(gdb)
lldb-mi  ProcessGDBRemote::DoLaunch() entered
lldb-mi  ProcessGDBRemote::DoLaunch provided with STDIO paths via
launch_info: stdin=/dev/pts/3, stdout=/dev/pts/3, stderr=/dev/pts/3
lldb-mi
GDBRemoteCommunication::StartDebugserverProcess(url=, port=0)
lldb-mi  GDBRemoteCommunication::StartDebugserverProcess() found
gdb-remote stub exe '/home/alexander/workspace/gsoc/build/bin/lldb-server'
lldb-mi  launch info for gdb-remote stub:
Executable: lldb-server
Triple: *-*-*
Arguments:
argv[0]="/home/alexander/workspace/gsoc/build/bin/lldb-server"
argv[1]="gdbserver"
argv[2]="--fd=5"
argv[3]="--native-regs"
argv[4]="--setsid"
argv[5]=NULL

Environment:
env[USER] = alexander
env[XAUTHORITY] = /run/user/1000/gdm/Xauthority
env[LOGNAME] = alexander
env[DEFAULTS_PATH] = /usr/share/gconf/gnome.default.path
env[XDG_RUNTIME_DIR] = /run/user/1000
env[LC_PAPER] = ru_RU.UTF-8
env[HOME] = /home/alexander
env[GIT_EDITOR] = vim
env[OLDPWD] = /home/alexander
env[XDG_DATA_DIRS] =
/usr/share/gnome:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop
env[LC_NAME] = ru_RU.UTF-8
env[LS_COLORS] =
rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:
env[TILIX_ID] = 6ddac5a9-51b9-4cfa-9eb4-6d0b34d0f04d
env[XMODIFIERS] = @im=ibus
env[LC_MONETARY] = ru_RU.UTF-8
env[GNOME_DESKTOP_SESSION_ID] = this-is-deprecated
env[GTK_IM_MODULE] = ibus
env[LANG] = en_US.UTF-8
env[QT_LINUX_ACCESSIBILITY_ALWAYS_ON] = 1
env[XDG_CONFIG_DIRS] = /etc/xdg/xdg-gnome:/etc/xdg
env[SSH_AUTH_SOCK] = /run/user/1000/keyring/ssh
env[XDG_SESSION_ID] = 1
env[LC_TELEPHONE] = ru_RU.UTF-8
env[LC_ADDRESS] = ru_RU.UTF-8
env[LC_MEASUREMENT] = ru_RU.UTF-8
env[SHELL] = /bin/bash
env[TERM] = xterm-256color
env[MANDATORY_PATH] = /usr/share/gconf/gnome.mandatory.path
env[CLUTTER_IM_MODULE] = xim
env[DBUS_SESSION_BUS_ADDRESS] =
unix:abstract=/tmp/dbus-oNfLOnXWYU,guid=f7166ac689c7f7e4acb976a25b72be95
env[USERNAME] = alexander
env[LC_NUMERIC] = ru_RU.UTF-8
env[XDG_MENU_PREFIX] = gnome-
env[WINDOWPATH] = 2
env[XDG_SESSION_TYPE] = x11
env[SHLVL] = 1
env[LESSOPEN] = | /usr/bin/lesspipe %s
env[PWD] = /home/alexander/workspace/gsoc
env[LESSCLOSE] = /usr/bin/lesspipe %s %s
env[XDG_SEAT] = seat0
env[QT4_IM_MODULE] = xim
env[DISPLAY] = :1
env[SSH_AGENT_PID] = 2049
env[LC_IDENTIFICATION] = ru_RU.UTF-8
env[GDMSESSION] = gnome
env[LC_TIME] = ru_RU.UTF-8
env[SESSION_MANAGER] = local/asus-k551:@
/tmp/.ICE-unix/1976,unix/asus-k551:/tmp/.ICE-unix/1976
env[GTK_MODULES] = gail:atk-bridge
env[XDG_SESSION_DESKTOP] = gnome
env[XDG_CURRENT_DESKTOP] = GNOME
env[_] = build/bin/lldb-mi
env[XDG_VTNR] = 2
env[QT_ACCESSIBILITY] = 1
env[PATH] =
/home/alexander/firmware/arc/arcanist/bin:/home/alexander/bin:/home/alexander/.local/bin:/home/alexander/firmware/arc/arcanist/bin:/usr/local/sbin:/usr/local/bin

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

[via lldb-dev]

That looks normal, up until the A packet failure. I’m building ToT lldb-mi 
right now on Ubuntu 14.04. What OS are you running on?

 

From: Александр Поляков  
Sent: Tuesday, August 14, 2018 4:56 PM
To: Adrian Prantl 
Cc: Ted Woodward ; LLDB 
Subject: Re: [lldb-dev] Failing LIT-based lldb-mi tests

 

Yes, it is. Here is the gdb-remote process log:

(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

(gdb)

^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0040051f",func="main",file="main.c",fullname="/home/alexander/workspace/gsoc/main.c",line="2",times="0",original-location="main"}

(gdb)

=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0040051f",func="main",file="main.c",fullname="/home/alexander/workspace/gsoc/main.c",line="2",times="0",original-location="main"}

(gdb)

^done

(gdb)

lldb-mi  ProcessGDBRemote::DoLaunch() entered

lldb-mi  ProcessGDBRemote::DoLaunch provided with STDIO paths via 
launch_info: stdin=/dev/pts/3, stdout=/dev/pts/3, stderr=/dev/pts/3

lldb-mi  GDBRemoteCommunication::StartDebugserverProcess(url=, 
port=0)

lldb-mi  GDBRemoteCommunication::StartDebugserverProcess() found 
gdb-remote stub exe '/home/alexander/workspace/gsoc/build/bin/lldb-server'

lldb-mi  launch info for gdb-remote stub:

Executable: lldb-server

Triple: *-*-*

Arguments:

argv[0]="/home/alexander/workspace/gsoc/build/bin/lldb-server"

argv[1]="gdbserver"

argv[2]="--fd=5"

argv[3]="--native-regs"

argv[4]="--setsid"

argv[5]=NULL

 

Environment:

env[USER] = alexander

env[XAUTHORITY] = /run/user/1000/gdm/Xauthority

env[LOGNAME] = alexander

env[DEFAULTS_PATH] = /usr/share/gconf/gnome.default.path

env[XDG_RUNTIME_DIR] = /run/user/1000

env[LC_PAPER] = ru_RU.UTF-8

env[HOME] = /home/alexander

env[GIT_EDITOR] = vim

env[OLDPWD] = /home/alexander

env[XDG_DATA_DIRS] = 
/usr/share/gnome:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop

env[LC_NAME] = ru_RU.UTF-8

env[LS_COLORS] = 
rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:

env[TILIX_ID] = 6ddac5a9-51b9-4cfa-9eb4-6d0b34d0f04d

env[XMODIFIERS] = @im=ibus

env[LC_MONETARY] = ru_RU.UTF-8

env[GNOME_DESKTOP_SESSION_ID] = this-is-deprecated

env[GTK_IM_MODULE] = ibus

env[LANG] = en_US.UTF-8

env[QT_LINUX_ACCESSIBILITY_ALWAYS_ON] = 1

env[XDG_CONFIG_DIRS] = /etc/xdg/xdg-gnome:/etc/xdg

env[SSH_AUTH_SOCK] = /run/user/1000/keyring/ssh

env[XDG_SESSION_ID] = 1

env[LC_TELEPHONE] = ru_RU.UTF-8

env[LC_ADDRESS] = ru_RU.UTF-8

env[LC_MEASUREMENT] = ru_RU.UTF-8

env[SHELL] = /bin/bash

env[TERM] = xterm-256color

env[MANDATORY_PATH] = /usr/share/gconf/gnome.mandatory.path

env[CLUTTER_IM_MODULE] = xim

env[DBUS_SESSION_BUS_ADDRESS] = 
unix:abstract=/tmp/dbus-oNfLOnXWYU,guid=f7166ac689c7f7e4acb976a25b72be95

env[USERNAME] = alexander

env[LC_NUMERIC] = ru_RU.UTF-8

env[XDG_MENU_PREFIX] = gnome-

env[WINDOWPATH] = 2

env[XDG_SESSION_TYPE] = x11

env[SHLVL] = 1

env[LESSOPEN] = | /usr/bin/lesspipe %s

env[PWD] = /home/alexander/workspace/gsoc

env[LESSCLOSE] = /usr/bin/lesspipe %s %s

env[XDG_SEAT] = seat0

env[QT4_IM_MODULE] = xim

env[DISPLAY] = :1

env[SSH_AGENT_PID] = 2049

env[LC_IDENTIFICATION] = ru_RU.UTF-8

env[GDMSESSION] = gnome

env[LC_TIME] = ru_RU.UTF-8

env[SESSION_MANAGER] = 
local/

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

[Александр Поляков via lldb-dev]

I'm running Ubuntu 16.04. The lldb-mi behaves in such a way randomly, the
only thing that in my opinion can lead to this error is high busyness of
the machine that runs debug session, but I'm not sure.

On Wed, Aug 15, 2018 at 12:59 AM  wrote:

> That looks normal, up until the A packet failure. I’m building ToT lldb-mi
> right now on Ubuntu 14.04. What OS are you running on?
>
>
>
> *From:* Александр Поляков 
> *Sent:* Tuesday, August 14, 2018 4:56 PM
> *To:* Adrian Prantl 
> *Cc:* Ted Woodward ; LLDB <
> lldb-dev@lists.llvm.org>
> *Subject:* Re: [lldb-dev] Failing LIT-based lldb-mi tests
>
>
>
> Yes, it is. Here is the gdb-remote process log:
>
> (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
>
> (gdb)
>
>
> ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0040051f",func="main",file="main.c",fullname="/home/alexander/workspace/gsoc/main.c",line="2",times="0",original-location="main"}
>
> (gdb)
>
>
> =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0040051f",func="main",file="main.c",fullname="/home/alexander/workspace/gsoc/main.c",line="2",times="0",original-location="main"}
>
> (gdb)
>
> ^done
>
> (gdb)
>
> lldb-mi  ProcessGDBRemote::DoLaunch() entered
>
> lldb-mi  ProcessGDBRemote::DoLaunch provided with STDIO paths via
> launch_info: stdin=/dev/pts/3, stdout=/dev/pts/3, stderr=/dev/pts/3
>
> lldb-mi
> GDBRemoteCommunication::StartDebugserverProcess(url=, port=0)
>
> lldb-mi  GDBRemoteCommunication::StartDebugserverProcess() found
> gdb-remote stub exe '/home/alexander/workspace/gsoc/build/bin/lldb-server'
>
> lldb-mi  launch info for gdb-remote stub:
>
> Executable: lldb-server
>
> Triple: *-*-*
>
> Arguments:
>
> argv[0]="/home/alexander/workspace/gsoc/build/bin/lldb-server"
>
> argv[1]="gdbserver"
>
> argv[2]="--fd=5"
>
> argv[3]="--native-regs"
>
> argv[4]="--setsid"
>
> argv[5]=NULL
>
>
>
> Environment:
>
> env[USER] = alexander
>
> env[XAUTHORITY] = /run/user/1000/gdm/Xauthority
>
> env[LOGNAME] = alexander
>
> env[DEFAULTS_PATH] = /usr/share/gconf/gnome.default.path
>
> env[XDG_RUNTIME_DIR] = /run/user/1000
>
> env[LC_PAPER] = ru_RU.UTF-8
>
> env[HOME] = /home/alexander
>
> env[GIT_EDITOR] = vim
>
> env[OLDPWD] = /home/alexander
>
> env[XDG_DATA_DIRS] =
> /usr/share/gnome:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop
>
> env[LC_NAME] = ru_RU.UTF-8
>
> env[LS_COLORS] =
> rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:
>
> env[TILIX_ID] = 6ddac5a9-51b9-4cfa-9eb4-6d0b34d0f04d
>
> env[XMODIFIERS] = @im=ibus
>
> env[LC_MONETARY] = ru_RU.UTF-8
>
> env[GNOME_DESKTOP_SESSION_ID] = this-is-deprecated
>
> env[GTK_IM_MODULE] = ibus
>
> env[LANG] = en_US.UTF-8
>
> env[QT_LINUX_ACCESSIBILITY_ALWAYS_ON] = 1
>
> env[XDG_CONFIG_DIRS] = /etc/xdg/xdg-gnome:/etc/xdg
>
> env[SSH_AUTH_SOCK] = /run/user/1000/keyring/ssh
>
> env[XDG_SESSION_ID] = 1
>
> env[LC_TELEPHONE] = ru_RU.UTF-8
>
> env[LC_ADDRESS] = ru_RU.UTF-8
>
> env[LC_MEASUREMENT] = ru_RU.UTF-8
>
> env[SHELL] = /bin/bash
>
> env[TERM] = xterm-256color
>
> env[MANDATORY_PATH] = /usr/share/gconf/gnome.mandatory.path
>
> env[CLUTTER_IM_MODULE] = xim
>
> env[DBUS_SESSION_BUS_ADDRESS] =
> unix:abstract=/tmp/dbus-oNfLOnXWYU,guid=f71

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

[via lldb-dev]

Yes, the communications back and forth indicate that lldb-server is running and 
lldb-mi is connected to it.

 

My run was successful. You mentioned load on the machine; do you see any failed 
runs from lldb? Both lldb and lldb-mi make the same call (Target::Launch) to 
start the process.

 

My log looks like this:

lldb-mi  <   1> send packet: +

lldb-mi  history[1] tid=0x33d0 <   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=2;QStartNoAckMode+;QThreadS

uffixSupported+;QListThreadsInStopReply+;qEcho+;QPassSignals+;qXfer:auxv:read+#b

e

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  < 363> read packet: 
$triple:7838365f36342d2d6c696e75782d676e75;ptrsize:8;distribution_id:7562756e7475;watchpoint_exceptions_received:after;endian:little;os_version:3.13.0;os_build:332e31332e302d3135332d67656e65726963;os_kernel:233230332d5562756e747520534d5020546875204a756e2031342030383a35323a3238205554432032303138;hostname:746564776f6f642d7562756e74752e7175616c636f6d6d2e636f6d;#73

lldb-mi  <  10> send packet: $vCont?#49

lldb-mi  <  17> read packet: $vCont;c;C;s;S#62

lldb-mi  <  27> send packet: $qVAttachOrWaitSupported#38

lldb-mi  <   4> read packet: $#00

lldb-mi  <  23> send packet: $QEnableErrorStrings#8c

lldb-mi  <   6> read packet: $OK#9a

lldb-mi  <  36> send packet: $QSetSTDIN:2f6465762f7074732f3235#4c

lldb-mi  <   6> read packet: $OK#9a

lldb-mi  <  37> send packet: $QSetSTDOUT:2f6465762f7074732f3235#ad

lldb-mi  <   6> read packet: $OK#9a

lldb-mi  <  37> send packet: $QSetSTDERR:2f6465762f7074732f3235#9e

lldb-mi  <   6> read packet: $OK#9a

lldb-mi  <  21> send packet: $QSetDisableASLR:1#ce

lldb-mi  <   6> read packet: $OK#9a

lldb-mi  <  23> send packet: $QSetDetachOnError:1#f8

lldb-mi  <   6> read packet: $OK#9a

lldb-mi  <  22> send packet: $QLaunchArch:x86_64#13

lldb-mi  <   6> read packet: $OK#9a

lldb-mi  <  72> send packet: $A62,0,2f757372322f746564776f6f642f6c6c6462

5f746573742f666163746c696e#19

lldb-mi  <   6> read packet: $OK#9a

lldb-mi  <  18> send packet: $qLaunchSuccess#a5

lldb-mi  <   6> read packet: $OK#9a

lldb-mi  <  16> send packet: $qProcessInfo#dc

lldb-mi  < 172> read packet: 
$pid:378a;parent-pid:3785;real-uid:34004;real-gid:c8;effective-uid:34004;effective-gid:c8;triple:7838365f36342d2d6c696e7578

 

the rest of the log is full of qRegisterInfo and other packets from a 
successful run.

 

From: apra...@apple.com  
Sent: Tuesday, August 14, 2018 4:50 PM
To: Александр Поляков 
Cc: Ted Woodward ; LLDB 
Subject: Re: [lldb-dev] Failing LIT-based lldb-mi tests

 

 





On Aug 14, 2018, at 2:43 PM, Александр Поляков mailto:polyakov@gmail.com> > wrote:

 

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=2;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?

 

 

Just to clarify: Is this from a session that failed with the symptoms you 
described earlier?

I'm not familiar with the protocol, but the fact that there are send and read 
log entries makes it sound like the communication itself is working.

 

-- adrian

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Александр Поляков via lldb-dev]

LLDB fails with the same symptoms:

lldb <   1> send packet: +
lldb history[1] tid=0x0c09 <   1> send packet: +
lldb <  19> send packet: $QStartNoAckMode#b0
lldb <   1> read packet: +
lldb <   6> read packet: $OK#9a
lldb <   1> send packet: +
lldb <  41> send packet:
$qSupported:xmlRegisters=i386,arm,mips#12
lldb < 124> read packet:
$PacketSize=2;QStartNoAckMode+;QThreadSuffixSupported+;QListThreadsInStopReply+;qEcho+;QPassSignals+;qXfer:auxv:read+#be
lldb <  26> send packet: $QThreadSuffixSupported#e4
lldb <   6> read packet: $OK#9a
lldb <  27> send packet: $QListThreadsInStopReply#21
lldb <   6> read packet: $OK#9a
lldb <  13> send packet: $qHostInfo#9b
lldb <  11> send packet: $qEcho:1#5b
error: process launch failed: 'A' packet returned an error: -1

`gdb-remote process` log is the same as for lldb-mi.

On Wed, Aug 15, 2018 at 2:01 AM  wrote:

> Yes, the communications back and forth indicate that lldb-server is
> running and lldb-mi is connected to it.
>
>
>
> My run was successful. You mentioned load on the machine; do you see any
> failed runs from lldb? Both lldb and lldb-mi make the same call
> (Target::Launch) to start the process.
>
>
>
> My log looks like this:
>
> lldb-mi  <   1> send packet: +
>
> lldb-mi  history[1] tid=0x33d0 <   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=2;QStartNoAckMode+;QThreadS
>
>
> uffixSupported+;QListThreadsInStopReply+;qEcho+;QPassSignals+;qXfer:auxv:read+#b
>
> e
>
> 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  < 363> read packet:
> $triple:7838365f36342d2d6c696e75782d676e75;ptrsize:8;distribution_id:7562756e7475;watchpoint_exceptions_received:after;endian:little;os_version:3.13.0;os_build:332e31332e302d3135332d67656e65726963;os_kernel:233230332d5562756e747520534d5020546875204a756e2031342030383a35323a3238205554432032303138;hostname:746564776f6f642d7562756e74752e7175616c636f6d6d2e636f6d;#73
>
> lldb-mi  <  10> send packet: $vCont?#49
>
> lldb-mi  <  17> read packet: $vCont;c;C;s;S#62
>
> lldb-mi  <  27> send packet: $qVAttachOrWaitSupported#38
>
> lldb-mi  <   4> read packet: $#00
>
> lldb-mi  <  23> send packet: $QEnableErrorStrings#8c
>
> lldb-mi  <   6> read packet: $OK#9a
>
> lldb-mi  <  36> send packet: $QSetSTDIN:2f6465762f7074732f3235#4c
>
> lldb-mi  <   6> read packet: $OK#9a
>
> lldb-mi  <  37> send packet: $QSetSTDOUT:2f6465762f7074732f3235#ad
>
> lldb-mi  <   6> read packet: $OK#9a
>
> lldb-mi  <  37> send packet: $QSetSTDERR:2f6465762f7074732f3235#9e
>
> lldb-mi  <   6> read packet: $OK#9a
>
> lldb-mi  <  21> send packet: $QSetDisableASLR:1#ce
>
> lldb-mi  <   6> read packet: $OK#9a
>
> lldb-mi  <  23> send packet: $QSetDetachOnError:1#f8
>
> lldb-mi  <   6> read packet: $OK#9a
>
> lldb-mi  <  22> send packet: $QLaunchArch:x86_64#13
>
> lldb-mi  <   6> read packet: $OK#9a
>
> lldb-mi  <  72> send packet:
> $A62,0,2f757372322f746564776f6f642f6c6c6462
>
> 5f746573742f666163746c696e#19
>
> lldb-mi  <   6> read packet: $OK#9a
>
> lldb-mi  <  18> send packet: $qLaunchSuccess#a5
>
> lldb-mi  <   6> read packet: $OK#9a
>
> lldb-mi  <  16> send packet: $qProcessInfo#dc
>
> lldb-mi  < 172> read packet:
> $pid:378a;parent-pid:3785;real-uid:34004;real-gid:c8;effective-uid:34004;effective-gid:c8;triple:7838365f36342d2d6c696e7578
>
>
>
> the rest of the log is full of qRegisterInfo and other packets from a
> successful run.
>
>
>
> *From:* apra...@apple.com 
> *Sent:* Tuesday, August 14, 2018 4:50 PM
> *To:* Александр Поляков 
> *Cc:* Ted Woodward ; LLDB <
> lldb-dev@lists.llvm.org>
> *Subject:* Re: [lldb-dev] Failing LIT-based lldb-mi tests
>
>
>
>
>
>
>
> On Aug 14, 2018, at 2:43 PM, Александр Поляков 
> wrote:
>
>
>
> 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:x

[lldb-dev] Using FileCheck in lldb inline tests

[Vedant Kumar via lldb-dev]

Hello,

I'd like to make FileCheck available within lldb inline tests, in addition to 
existing helpers like 'runCmd' and 'expect'.

My motivation is that several tests I'm working on can't be made as rigorous as 
they need to be without FileCheck-style checks. In particular, the 'matching', 
'substrs', and 'patterns' arguments to runCmd/expect don't allow me to verify 
the ordering of checked input, to be stringent about line numbers, or to 
capture & reuse snippets of text from the input stream.

I'd curious to know if anyone else is interested or would be willing to review 
this (https://reviews.llvm.org/D50751 ).

Here's an example of an inline test which benefits from FileCheck-style 
checking. This test is trying to check that certain frames appear in a 
backtrace when stopped inside of the "sink" function. Notice that without 
FileCheck, it's not possible to verify the order in which frames are printed, 
and that dealing with line numbers would be cumbersome.

```
--- 
a/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/unambiguous_sequence/main.cpp
+++ 
b/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/unambiguous_sequence/main.cpp
@@ -9,16 +9,21 @@
 
 volatile int x;
 
+// CHECK: frame #0: {{.*}}sink() at main.cpp:[[@LINE+2]] [opt]
 void __attribute__((noinline)) sink() {
-  x++; //% self.expect("bt", substrs = ['main', 'func1', 'func2', 'func3', 
'sink'])
+  x++; //% self.filecheck("bt", "main.cpp")
 }
 
+// CHECK-NEXT: frame #1: {{.*}}func3() {{.*}}[opt] [artificial]
 void __attribute__((noinline)) func3() { sink(); /* tail */ }
 
+// CHECK-NEXT: frame #2: {{.*}}func2() at main.cpp:[[@LINE+1]] [opt]
 void __attribute__((disable_tail_calls, noinline)) func2() { func3(); /* 
regular */ }
 
+// CHECK-NEXT: frame #3: {{.*}}func1() {{.*}}[opt] [artificial]
 void __attribute__((noinline)) func1() { func2(); /* tail */ }
 
+// CHECK-NEXT: frame #4: {{.*}}main at main.cpp:[[@LINE+2]] [opt]
 int __attribute__((disable_tail_calls)) main() {
   func1(); /* regular */
   return 0;
```

For reference, here's the output of the "bt" command:

```
runCmd: bt
output: * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 
1.1
  * frame #0: 0x00010c6a6f64 a.out`sink() at main.cpp:14 [opt]
frame #1: 0x00010c6a6f70 a.out`func3() at main.cpp:15 [opt] [artificial]
frame #2: 0x00010c6a6f89 a.out`func2() at main.cpp:21 [opt]
frame #3: 0x00010c6a6f90 a.out`func1() at main.cpp:21 [opt] [artificial]
frame #4: 0x00010c6a6fa9 a.out`main at main.cpp:28 [opt]
```

thanks,
vedant
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Using FileCheck in lldb inline tests

[Zachary Turner via lldb-dev]

I’ve thought about this in the past but the conclusion I came to is that
lldbinline tests are actually just filecheck tests in disguise. Why do we
need both? I’d rather delete the lldbinline infrastructure entirely and
make a new lit TestFormat that basically does what lldbinline already does
On Tue, Aug 14, 2018 at 5:31 PM Vedant Kumar via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hello,
>
> I'd like to make FileCheck available within lldb inline tests, in addition
> to existing helpers like 'runCmd' and 'expect'.
>
> My motivation is that several tests I'm working on can't be made as
> rigorous as they need to be without FileCheck-style checks. In particular,
> the 'matching', 'substrs', and 'patterns' arguments to runCmd/expect don't
> allow me to verify the ordering of checked input, to be stringent about
> line numbers, or to capture & reuse snippets of text from the input stream.
>
> I'd curious to know if anyone else is interested or would be willing to
> review this (https://reviews.llvm.org/D50751).
>
> Here's an example of an inline test which benefits from FileCheck-style
> checking. This test is trying to check that certain frames appear in a
> backtrace when stopped inside of the "sink" function. Notice that without
> FileCheck, it's not possible to verify the order in which frames are
> printed, and that dealing with line numbers would be cumbersome.
>
> ```
> ---
> a/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/unambiguous_sequence/main.cpp
> +++
> b/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/unambiguous_sequence/main.cpp
> @@ -9,16 +9,21 @@
>
>  volatile int x;
>
> +// CHECK: frame #0: {{.*}}sink() at main.cpp:[[@LINE+2]] [opt]
>  void __attribute__((noinline)) sink() {
> -  x++; //% self.expect("bt", substrs = ['main', 'func1', 'func2',
> 'func3', 'sink'])
> +  x++; //% self.filecheck("bt", "main.cpp")
>  }
>
> +// CHECK-NEXT: frame #1: {{.*}}func3() {{.*}}[opt] [artificial]
>  void __attribute__((noinline)) func3() { sink(); /* tail */ }
>
> +// CHECK-NEXT: frame #2: {{.*}}func2() at main.cpp:[[@LINE+1]] [opt]
>  void __attribute__((disable_tail_calls, noinline)) func2() { func3(); /*
> regular */ }
>
> +// CHECK-NEXT: frame #3: {{.*}}func1() {{.*}}[opt] [artificial]
>  void __attribute__((noinline)) func1() { func2(); /* tail */ }
>
> +// CHECK-NEXT: frame #4: {{.*}}main at main.cpp:[[@LINE+2]] [opt]
>  int __attribute__((disable_tail_calls)) main() {
>func1(); /* regular */
>return 0;
> ```
>
> For reference, here's the output of the "bt" command:
>
> ```
> runCmd: bt
> output: * thread #1, queue = 'com.apple.main-thread', stop reason =
> breakpoint 1.1
>   * frame #0: 0x00010c6a6f64 a.out`sink() at main.cpp:14 [opt]
> frame #1: 0x00010c6a6f70 a.out`func3() at main.cpp:15 [opt]
> [artificial]
> frame #2: 0x00010c6a6f89 a.out`func2() at main.cpp:21 [opt]
> frame #3: 0x00010c6a6f90 a.out`func1() at main.cpp:21 [opt]
> [artificial]
> frame #4: 0x00010c6a6fa9 a.out`main at main.cpp:28 [opt]
> ```
>
> thanks,
> vedant
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Using FileCheck in lldb inline tests

[Jason Molenda via lldb-dev]

I'd argue against this approach because it's exactly why the lit tests don't 
run against the lldb driver -- they're hardcoding the output of the lldb driver 
command into the testsuite and these will eventually make it much more 
difficult to change and improve the driver as we've accumulated this style of 
test.

This is a perfect test for a normal SB API.  Run to your breakpoints and check 
the stack frames.

  f0 = thread.GetFrameAtIndex(0)
  check that f0.GetFunctionName() == sink
  check that f0.IsArtifical() == True
  check that f0.GetLineEntry().GetLine() == expected line number


it's more verbose, but it's also much more explicit about what it's checking, 
and easy to see what has changed if there is a failure.


J

> On Aug 14, 2018, at 5:31 PM, Vedant Kumar via lldb-dev 
>  wrote:
> 
> Hello,
> 
> I'd like to make FileCheck available within lldb inline tests, in addition to 
> existing helpers like 'runCmd' and 'expect'.
> 
> My motivation is that several tests I'm working on can't be made as rigorous 
> as they need to be without FileCheck-style checks. In particular, the 
> 'matching', 'substrs', and 'patterns' arguments to runCmd/expect don't allow 
> me to verify the ordering of checked input, to be stringent about line 
> numbers, or to capture & reuse snippets of text from the input stream.
> 
> I'd curious to know if anyone else is interested or would be willing to 
> review this (https://reviews.llvm.org/D50751).
> 
> Here's an example of an inline test which benefits from FileCheck-style 
> checking. This test is trying to check that certain frames appear in a 
> backtrace when stopped inside of the "sink" function. Notice that without 
> FileCheck, it's not possible to verify the order in which frames are printed, 
> and that dealing with line numbers would be cumbersome.
> 
> ```
> --- 
> a/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/unambiguous_sequence/main.cpp
> +++ 
> b/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/unambiguous_sequence/main.cpp
> @@ -9,16 +9,21 @@
>  
>  volatile int x;
>  
> +// CHECK: frame #0: {{.*}}sink() at main.cpp:[[@LINE+2]] [opt]
>  void __attribute__((noinline)) sink() {
> -  x++; //% self.expect("bt", substrs = ['main', 'func1', 'func2', 'func3', 
> 'sink'])
> +  x++; //% self.filecheck("bt", "main.cpp")
>  }
>  
> +// CHECK-NEXT: frame #1: {{.*}}func3() {{.*}}[opt] [artificial]
>  void __attribute__((noinline)) func3() { sink(); /* tail */ }
>  
> +// CHECK-NEXT: frame #2: {{.*}}func2() at main.cpp:[[@LINE+1]] [opt]
>  void __attribute__((disable_tail_calls, noinline)) func2() { func3(); /* 
> regular */ }
>  
> +// CHECK-NEXT: frame #3: {{.*}}func1() {{.*}}[opt] [artificial]
>  void __attribute__((noinline)) func1() { func2(); /* tail */ }
>  
> +// CHECK-NEXT: frame #4: {{.*}}main at main.cpp:[[@LINE+2]] [opt]
>  int __attribute__((disable_tail_calls)) main() {
>func1(); /* regular */
>return 0;
> ```
> 
> For reference, here's the output of the "bt" command:
> 
> ```
> runCmd: bt
> output: * thread #1, queue = 'com.apple.main-thread', stop reason = 
> breakpoint 1.1
>   * frame #0: 0x00010c6a6f64 a.out`sink() at main.cpp:14 [opt]
> frame #1: 0x00010c6a6f70 a.out`func3() at main.cpp:15 [opt] 
> [artificial]
> frame #2: 0x00010c6a6f89 a.out`func2() at main.cpp:21 [opt]
> frame #3: 0x00010c6a6f90 a.out`func1() at main.cpp:21 [opt] 
> [artificial]
> frame #4: 0x00010c6a6fa9 a.out`main at main.cpp:28 [opt]
> ```
> 
> thanks,
> vedant
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] stable layout bug for imported record decls.

[Lang Hames via lldb-dev]

Hi Gábor, Richard,

Hi Richard, maybe my understanding is not correct, but I believe the
> situation is somewhat twisted and reversed...


Is this relationship recursive? (Should it be?) I.e. When ClangASTSource
uses ASTImporter to minimally import a Decl, should that Decl have another
ExternalASTSource attached (possibly the original ClangASTSource) to
complete the minimally imported Decl on demand?

-- Lang.

On Tue, Aug 14, 2018 at 6:49 AM Gábor Márton  wrote:

> > It might be interesting to consider how this is addressed by the
> ExternalASTSource interface. There, we have separate "import the lexical
> contents of this AST node (including populating the lexical declarations
> list with all members, in the right order)", "import the lookup results for
> this name in this context (and cache them but don't add them to the list of
> lexical members)" and "import this specific declaration member (but don't
> add it to the list of lexical members)" queries. One could imagine doing
> something similar for the AST importer: when you're performing a minimal
> import but you want to import a method declaration, don't insert it into
> the list of lexical members of the enclosing record. Instead, defer doing
> that until a complete type is required (at that point, you'd need to import
> all the relevant members anyway, including the base classes and virtual
> functions in the right order).
>
> Hi Richard, maybe my understanding is not correct, but I believe the
> situation is somewhat twisted and reversed.
> Seems like LLDB already exercises the ExternalASTSource interface. The
> purpose of using it is exactly to load the external lexical contents
> of an AST node (as you suggested). However, the load is implemented by
> the means of the ASTImporter (in minimal mode). Consider the attached
> function call trace:
> When the user instructs LLDB to evaluate an expression then LLDB
> exercises the parser `clang::ParseAST`, which in turn does a lookup
> `clang::DeclContext::lookup`. During the lookup,
> `lldb_private::ClangASTSource::FindExternalVisibleDeclsByName` is
> called (this function overloads
> `ExternalASTSource::FindExternalVisibleDeclsByName`).
> And finally, through `lldb_private::ClangASTImporter::CopyType` we end
> up in `clang::ASTImporter::Import`.
>
> Gabor
>
> ```
> #4  0x741a72ed in clang::ASTNodeImporter::ImportDeclParts
> (this=this@entry=0x7fff8be0, D=D@entry=0x632038,
> DC=@0x7fff8ac8: 0x0,
> LexicalDC=@0x7fff8ad0: 0x0, Name=..., ToD=@0x7fff8ad8: 0x0,
> Loc=...)
> at
> /home/gerazo/repos/codechecker_dev_env/CTU/llvm/tools/clang/lib/AST/ASTImporter.cpp:1062
> #5  0x741a8d55 in clang::ASTNodeImporter::VisitRecordDecl
> (this=0x7fff8be0, D=0x632038)
> at
> /home/gerazo/repos/codechecker_dev_env/CTU/llvm/tools/clang/lib/AST/ASTImporter.cpp:2126
> #6  0x7419377b in clang::ASTImporter::Import (this=0x70cc90,
> FromD=0x632038)
> at
> /home/gerazo/repos/codechecker_dev_env/CTU/llvm/tools/clang/lib/AST/ASTImporter.cpp:7054
> #7  0x741939f7 in clang::ASTNodeImporter::VisitRecordType
> (this=0x7fff8c40, T=)
> at
> /home/gerazo/repos/codechecker_dev_env/CTU/llvm/tools/clang/lib/AST/ASTImporter.cpp:851
> #8  0x74196f65 in clang::TypeVisitor clang::QualType>::Visit (this=this@entry=0x7fff8c40, T= out>)
> at
> /home/gerazo/repos/codechecker_dev_env/CTU/llvm/tools/clang/include/clang/AST/TypeNodes.def:92
> #9  0x74197187 in clang::ASTImporter::Import (this=0x70cc90,
> FromT=FromT@entry=...)
> at
> /home/gerazo/repos/codechecker_dev_env/CTU/llvm/tools/clang/lib/AST/ASTImporter.cpp:6983
> #10 0x77351c92 in lldb_private::ClangASTImporter::CopyType
> (this=, dst_ast=, src_ast= out>, type=type@entry=...)
> at
> /home/gerazo/repos/codechecker_dev_env/CTU/llvm/tools/lldb/source/Symbol/ClangASTImporter.cpp:61
> #11 0x774bdb95 in
> lldb_private::ClangASTSource::GuardedCopyType
> (this=this@entry=0x611e20, src_type=...)
> at
> /home/gerazo/repos/codechecker_dev_env/CTU/llvm/tools/lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp:2040
> #12 0x774e9ffe in
> lldb_private::ClangExpressionDeclMap::GetVariableValue
> (this=this@entry=0x611e20, var=std::shared_ptr (count 6, weak 1)
> 0x7fffe80020f0,
> var_location=..., user_type=user_type@entry=0x7fff8fc0,
> parser_type=parser_type@entry=0x7fff8fe0)
> at
> /home/gerazo/repos/codechecker_dev_env/CTU/llvm/tools/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp:1627
> #13 0x774ea3a7 in
> lldb_private::ClangExpressionDeclMap::AddOneVariable
> (this=this@entry=0x611e20, context=...,
> var=std::shared_ptr (count 6, weak 1) 0x7fffe80020f0, valobj=...,
> current_id=current_id@entry=2)
> at
> /home/gerazo/repos/codechecker_dev_env/CTU/llvm/tools/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp:1679
> #14 0x774ec50b in
> lldb_private::ClangExpressionDeclMap::Fin

Re: [lldb-dev] Using FileCheck in lldb inline tests

[Vedant Kumar via lldb-dev]

It'd be easy to update FileCheck tests when changing the debugger (this happens 
all the time in clang/swift). OTOH, the verbosity of the python API means that 
fewer tests get written. I see a real need to make expressive tests easier to 
write.

vedant

> On Aug 14, 2018, at 5:38 PM, Jason Molenda  wrote:
> 
> I'd argue against this approach because it's exactly why the lit tests don't 
> run against the lldb driver -- they're hardcoding the output of the lldb 
> driver command into the testsuite and these will eventually make it much more 
> difficult to change and improve the driver as we've accumulated this style of 
> test.
> 
> This is a perfect test for a normal SB API.  Run to your breakpoints and 
> check the stack frames.
> 
>  f0 = thread.GetFrameAtIndex(0)
>  check that f0.GetFunctionName() == sink
>  check that f0.IsArtifical() == True
>  check that f0.GetLineEntry().GetLine() == expected line number
> 
> 
> it's more verbose, but it's also much more explicit about what it's checking, 
> and easy to see what has changed if there is a failure.
> 
> 
> J
> 
>> On Aug 14, 2018, at 5:31 PM, Vedant Kumar via lldb-dev 
>>  wrote:
>> 
>> Hello,
>> 
>> I'd like to make FileCheck available within lldb inline tests, in addition 
>> to existing helpers like 'runCmd' and 'expect'.
>> 
>> My motivation is that several tests I'm working on can't be made as rigorous 
>> as they need to be without FileCheck-style checks. In particular, the 
>> 'matching', 'substrs', and 'patterns' arguments to runCmd/expect don't allow 
>> me to verify the ordering of checked input, to be stringent about line 
>> numbers, or to capture & reuse snippets of text from the input stream.
>> 
>> I'd curious to know if anyone else is interested or would be willing to 
>> review this (https://reviews.llvm.org/D50751).
>> 
>> Here's an example of an inline test which benefits from FileCheck-style 
>> checking. This test is trying to check that certain frames appear in a 
>> backtrace when stopped inside of the "sink" function. Notice that without 
>> FileCheck, it's not possible to verify the order in which frames are 
>> printed, and that dealing with line numbers would be cumbersome.
>> 
>> ```
>> --- 
>> a/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/unambiguous_sequence/main.cpp
>> +++ 
>> b/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/unambiguous_sequence/main.cpp
>> @@ -9,16 +9,21 @@
>> 
>> volatile int x;
>> 
>> +// CHECK: frame #0: {{.*}}sink() at main.cpp:[[@LINE+2]] [opt]
>> void __attribute__((noinline)) sink() {
>> -  x++; //% self.expect("bt", substrs = ['main', 'func1', 'func2', 'func3', 
>> 'sink'])
>> +  x++; //% self.filecheck("bt", "main.cpp")
>> }
>> 
>> +// CHECK-NEXT: frame #1: {{.*}}func3() {{.*}}[opt] [artificial]
>> void __attribute__((noinline)) func3() { sink(); /* tail */ }
>> 
>> +// CHECK-NEXT: frame #2: {{.*}}func2() at main.cpp:[[@LINE+1]] [opt]
>> void __attribute__((disable_tail_calls, noinline)) func2() { func3(); /* 
>> regular */ }
>> 
>> +// CHECK-NEXT: frame #3: {{.*}}func1() {{.*}}[opt] [artificial]
>> void __attribute__((noinline)) func1() { func2(); /* tail */ }
>> 
>> +// CHECK-NEXT: frame #4: {{.*}}main at main.cpp:[[@LINE+2]] [opt]
>> int __attribute__((disable_tail_calls)) main() {
>>   func1(); /* regular */
>>   return 0;
>> ```
>> 
>> For reference, here's the output of the "bt" command:
>> 
>> ```
>> runCmd: bt
>> output: * thread #1, queue = 'com.apple.main-thread', stop reason = 
>> breakpoint 1.1
>>  * frame #0: 0x00010c6a6f64 a.out`sink() at main.cpp:14 [opt]
>>frame #1: 0x00010c6a6f70 a.out`func3() at main.cpp:15 [opt] 
>> [artificial]
>>frame #2: 0x00010c6a6f89 a.out`func2() at main.cpp:21 [opt]
>>frame #3: 0x00010c6a6f90 a.out`func1() at main.cpp:21 [opt] 
>> [artificial]
>>frame #4: 0x00010c6a6fa9 a.out`main at main.cpp:28 [opt]
>> ```
>> 
>> thanks,
>> vedant
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Using FileCheck in lldb inline tests

[Vedant Kumar via lldb-dev]

> On Aug 14, 2018, at 5:34 PM, Zachary Turner  wrote:
> 
> I’ve thought about this in the past but the conclusion I came to is that 
> lldbinline tests are actually just filecheck tests in disguise. Why do we 
> need both? I’d rather delete the lldbinline infrastructure entirely and make 
> a new lit TestFormat that basically does what lldbinline already does 

An inline test does more than simply pattern-matching input. It builds a 
program, sets breakpoints, etc. I'd rather make this existing infrastructure 
easier to use than come up with something new.

vedant


> On Tue, Aug 14, 2018 at 5:31 PM Vedant Kumar via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> Hello,
> 
> I'd like to make FileCheck available within lldb inline tests, in addition to 
> existing helpers like 'runCmd' and 'expect'.
> 
> My motivation is that several tests I'm working on can't be made as rigorous 
> as they need to be without FileCheck-style checks. In particular, the 
> 'matching', 'substrs', and 'patterns' arguments to runCmd/expect don't allow 
> me to verify the ordering of checked input, to be stringent about line 
> numbers, or to capture & reuse snippets of text from the input stream.
> 
> I'd curious to know if anyone else is interested or would be willing to 
> review this (https://reviews.llvm.org/D50751 
> ).
> 
> Here's an example of an inline test which benefits from FileCheck-style 
> checking. This test is trying to check that certain frames appear in a 
> backtrace when stopped inside of the "sink" function. Notice that without 
> FileCheck, it's not possible to verify the order in which frames are printed, 
> and that dealing with line numbers would be cumbersome.
> 
> ```
> --- 
> a/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/unambiguous_sequence/main.cpp
> +++ 
> b/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/unambiguous_sequence/main.cpp
> @@ -9,16 +9,21 @@
>  
>  volatile int x;
>  
> +// CHECK: frame #0: {{.*}}sink() at main.cpp:[[@LINE+2]] [opt]
>  void __attribute__((noinline)) sink() {
> -  x++; //% self.expect("bt", substrs = ['main', 'func1', 'func2', 'func3', 
> 'sink'])
> +  x++; //% self.filecheck("bt", "main.cpp")
>  }
>  
> +// CHECK-NEXT: frame #1: {{.*}}func3() {{.*}}[opt] [artificial]
>  void __attribute__((noinline)) func3() { sink(); /* tail */ }
>  
> +// CHECK-NEXT: frame #2: {{.*}}func2() at main.cpp:[[@LINE+1]] [opt]
>  void __attribute__((disable_tail_calls, noinline)) func2() { func3(); /* 
> regular */ }
>  
> +// CHECK-NEXT: frame #3: {{.*}}func1() {{.*}}[opt] [artificial]
>  void __attribute__((noinline)) func1() { func2(); /* tail */ }
>  
> +// CHECK-NEXT: frame #4: {{.*}}main at main.cpp:[[@LINE+2]] [opt]
>  int __attribute__((disable_tail_calls)) main() {
>func1(); /* regular */
>return 0;
> ```
> 
> For reference, here's the output of the "bt" command:
> 
> ```
> runCmd: bt
> output: * thread #1, queue = 'com.apple.main-thread', stop reason = 
> breakpoint 1.1
>   * frame #0: 0x00010c6a6f64 a.out`sink() at main.cpp:14 [opt]
> frame #1: 0x00010c6a6f70 a.out`func3() at main.cpp:15 [opt] 
> [artificial]
> frame #2: 0x00010c6a6f89 a.out`func2() at main.cpp:21 [opt]
> frame #3: 0x00010c6a6f90 a.out`func1() at main.cpp:21 [opt] 
> [artificial]
> frame #4: 0x00010c6a6fa9 a.out`main at main.cpp:28 [opt]
> ```
> 
> thanks,
> vedant
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Using FileCheck in lldb inline tests

[Zachary Turner via lldb-dev]

On Tue, Aug 14, 2018 at 5:56 PM Vedant Kumar  wrote:

>
>
> On Aug 14, 2018, at 5:34 PM, Zachary Turner  wrote:
>
> I’ve thought about this in the past but the conclusion I came to is that
> lldbinline tests are actually just filecheck tests in disguise. Why do we
> need both? I’d rather delete the lldbinline infrastructure entirely and
> make a new lit TestFormat that basically does what lldbinline already does
>
>
> An inline test does more than simply pattern-matching input. It builds a
> program, sets breakpoints, etc. I'd rather make this existing
> infrastructure easier to use than come up with something new.
>
> vedant
>

Right, but only one specific type of lit test  depends on pattern matching,
and those are the SHTest format tests.  You can make an arbitrary test
format, including one that builds programs, set breakpoints etc.  the
format and structure of an lldbinline test need not even change at all
(except that I think we could eliminate the .py file).  The lldbinline
tests are about as close to a drop in fit for lit as we can get, the only
thing that needs to happen is the code in lldbinline.py needs to move to
something called InlineTestFormat.py and then be hooked into lit
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Using FileCheck in lldb inline tests

[Jason Molenda via lldb-dev]

It's more verbose, and it does mean test writers need to learn the public API, 
but it's also much more stable and debuggable in the future.  It's a higher up 
front cost but we're paid back in being able to develop lldb more quickly in 
the future, where our published API behaviors are being tested directly, and 
the things that must not be broken.  The lldb driver's output isn't a contract, 
and treating it like one makes the debugger harder to innovate in the future.

It's also helpful when adding new features to ensure you've exposed the feature 
through the API sufficiently.  The first thing I thought to try when writing 
the example below was SBFrame::IsArtificial() (see SBFrame::IsInlined()) which 
doesn't exist.  If a driver / IDE is going to visually indicate artificial 
frames, they'll need that.

J

> On Aug 14, 2018, at 5:56 PM, Vedant Kumar  wrote:
> 
> It'd be easy to update FileCheck tests when changing the debugger (this 
> happens all the time in clang/swift). OTOH, the verbosity of the python API 
> means that fewer tests get written. I see a real need to make expressive 
> tests easier to write.
> 
> vedant
> 
>> On Aug 14, 2018, at 5:38 PM, Jason Molenda  wrote:
>> 
>> I'd argue against this approach because it's exactly why the lit tests don't 
>> run against the lldb driver -- they're hardcoding the output of the lldb 
>> driver command into the testsuite and these will eventually make it much 
>> more difficult to change and improve the driver as we've accumulated this 
>> style of test.
>> 
>> This is a perfect test for a normal SB API.  Run to your breakpoints and 
>> check the stack frames.
>> 
>> f0 = thread.GetFrameAtIndex(0)
>> check that f0.GetFunctionName() == sink
>> check that f0.IsArtifical() == True
>> check that f0.GetLineEntry().GetLine() == expected line number
>> 
>> 
>> it's more verbose, but it's also much more explicit about what it's 
>> checking, and easy to see what has changed if there is a failure.
>> 
>> 
>> J
>> 
>>> On Aug 14, 2018, at 5:31 PM, Vedant Kumar via lldb-dev 
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> I'd like to make FileCheck available within lldb inline tests, in addition 
>>> to existing helpers like 'runCmd' and 'expect'.
>>> 
>>> My motivation is that several tests I'm working on can't be made as 
>>> rigorous as they need to be without FileCheck-style checks. In particular, 
>>> the 'matching', 'substrs', and 'patterns' arguments to runCmd/expect don't 
>>> allow me to verify the ordering of checked input, to be stringent about 
>>> line numbers, or to capture & reuse snippets of text from the input stream.
>>> 
>>> I'd curious to know if anyone else is interested or would be willing to 
>>> review this (https://reviews.llvm.org/D50751).
>>> 
>>> Here's an example of an inline test which benefits from FileCheck-style 
>>> checking. This test is trying to check that certain frames appear in a 
>>> backtrace when stopped inside of the "sink" function. Notice that without 
>>> FileCheck, it's not possible to verify the order in which frames are 
>>> printed, and that dealing with line numbers would be cumbersome.
>>> 
>>> ```
>>> --- 
>>> a/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/unambiguous_sequence/main.cpp
>>> +++ 
>>> b/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/unambiguous_sequence/main.cpp
>>> @@ -9,16 +9,21 @@
>>> 
>>> volatile int x;
>>> 
>>> +// CHECK: frame #0: {{.*}}sink() at main.cpp:[[@LINE+2]] [opt]
>>> void __attribute__((noinline)) sink() {
>>> -  x++; //% self.expect("bt", substrs = ['main', 'func1', 'func2', 'func3', 
>>> 'sink'])
>>> +  x++; //% self.filecheck("bt", "main.cpp")
>>> }
>>> 
>>> +// CHECK-NEXT: frame #1: {{.*}}func3() {{.*}}[opt] [artificial]
>>> void __attribute__((noinline)) func3() { sink(); /* tail */ }
>>> 
>>> +// CHECK-NEXT: frame #2: {{.*}}func2() at main.cpp:[[@LINE+1]] [opt]
>>> void __attribute__((disable_tail_calls, noinline)) func2() { func3(); /* 
>>> regular */ }
>>> 
>>> +// CHECK-NEXT: frame #3: {{.*}}func1() {{.*}}[opt] [artificial]
>>> void __attribute__((noinline)) func1() { func2(); /* tail */ }
>>> 
>>> +// CHECK-NEXT: frame #4: {{.*}}main at main.cpp:[[@LINE+2]] [opt]
>>> int __attribute__((disable_tail_calls)) main() {
>>>  func1(); /* regular */
>>>  return 0;
>>> ```
>>> 
>>> For reference, here's the output of the "bt" command:
>>> 
>>> ```
>>> runCmd: bt
>>> output: * thread #1, queue = 'com.apple.main-thread', stop reason = 
>>> breakpoint 1.1
>>> * frame #0: 0x00010c6a6f64 a.out`sink() at main.cpp:14 [opt]
>>>   frame #1: 0x00010c6a6f70 a.out`func3() at main.cpp:15 [opt] 
>>> [artificial]
>>>   frame #2: 0x00010c6a6f89 a.out`func2() at main.cpp:21 [opt]
>>>   frame #3: 0x00010c6a6f90 a.out`func1() at main.cpp:21 [opt] 
>>> [artificial]
>>>   frame #4: 0x00010c6a6fa9 a.out`main at main.cpp:28 [opt]
>>> ```
>>> 
>>> thanks,
>>> vedant
>>> ___
>>> lldb-dev mailing list
>>

Re: [lldb-dev] Using FileCheck in lldb inline tests

[Zachary Turner via lldb-dev]

Having bugs also makes the debugger harder to innovate in the future
because it’s, not having tests leads to having bugs, and sb api tests leads
to not having tests. At the end of the day, it doesn’t matter how stable
the tests are if there arent enough of them. There should be about 10x-20x
as many tests as there are currently, and that will simply never happen
under the current approach. If it means we need to have multiple different
styles of test, so be it. The problem we face right now has nothing to do
with command output changing, and in fact I don’t that we’ve *ever* had
this problem. So we should be focusing on problems we have, not problems we
don’t have.

Note that it is not strictly necessary for a test to check the debuggers
command output. There could be a different set of commands whose only
purpose is to print information for the purposes of debugging. One idea
would be to introduce the notion of a debugger object model, where you
print various aspects of the debuggers state with an object like syntax.
For example,

(lldb) p debugger.targets
~/foo (running, pid: 123)

(lldb) p debugger.targets[0].threads[0].frames[1]
int main(int argc=3, char **argv=0x12345678) + 0x72

(lldb) p debugger.targets[0].threads[0].frames[1].params[0]
int argc=3

(lldb) p debugger.targets[0].breakpoints
[1] main.cpp:72

Etc. you can get arbitrarily granular and dxpose every detail of the
debuggers internal state this way, and the output is so simple that you
never have to worry about it changing.

That said, I think history has shown that limiting ourselves to sb api
tests, despite all the theoretical benefits, leads to insufficient test
coverage. So while it has benefits, it also has problems for which we need
a better solution
On Tue, Aug 14, 2018 at 6:19 PM Jason Molenda via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> It's more verbose, and it does mean test writers need to learn the public
> API, but it's also much more stable and debuggable in the future.  It's a
> higher up front cost but we're paid back in being able to develop lldb more
> quickly in the future, where our published API behaviors are being tested
> directly, and the things that must not be broken.  The lldb driver's output
> isn't a contract, and treating it like one makes the debugger harder to
> innovate in the future.
>
> It's also helpful when adding new features to ensure you've exposed the
> feature through the API sufficiently.  The first thing I thought to try
> when writing the example below was SBFrame::IsArtificial() (see
> SBFrame::IsInlined()) which doesn't exist.  If a driver / IDE is going to
> visually indicate artificial frames, they'll need that.
>
> J
>
> > On Aug 14, 2018, at 5:56 PM, Vedant Kumar  wrote:
> >
> > It'd be easy to update FileCheck tests when changing the debugger (this
> happens all the time in clang/swift). OTOH, the verbosity of the python API
> means that fewer tests get written. I see a real need to make expressive
> tests easier to write.
> >
> > vedant
> >
> >> On Aug 14, 2018, at 5:38 PM, Jason Molenda  wrote:
> >>
> >> I'd argue against this approach because it's exactly why the lit tests
> don't run against the lldb driver -- they're hardcoding the output of the
> lldb driver command into the testsuite and these will eventually make it
> much more difficult to change and improve the driver as we've accumulated
> this style of test.
> >>
> >> This is a perfect test for a normal SB API.  Run to your breakpoints
> and check the stack frames.
> >>
> >> f0 = thread.GetFrameAtIndex(0)
> >> check that f0.GetFunctionName() == sink
> >> check that f0.IsArtifical() == True
> >> check that f0.GetLineEntry().GetLine() == expected line number
> >>
> >>
> >> it's more verbose, but it's also much more explicit about what it's
> checking, and easy to see what has changed if there is a failure.
> >>
> >>
> >> J
> >>
> >>> On Aug 14, 2018, at 5:31 PM, Vedant Kumar via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>>
> >>> Hello,
> >>>
> >>> I'd like to make FileCheck available within lldb inline tests, in
> addition to existing helpers like 'runCmd' and 'expect'.
> >>>
> >>> My motivation is that several tests I'm working on can't be made as
> rigorous as they need to be without FileCheck-style checks. In particular,
> the 'matching', 'substrs', and 'patterns' arguments to runCmd/expect don't
> allow me to verify the ordering of checked input, to be stringent about
> line numbers, or to capture & reuse snippets of text from the input stream.
> >>>
> >>> I'd curious to know if anyone else is interested or would be willing
> to review this (https://reviews.llvm.org/D50751).
> >>>
> >>> Here's an example of an inline test which benefits from
> FileCheck-style checking. This test is trying to check that certain frames
> appear in a backtrace when stopped inside of the "sink" function. Notice
> that without FileCheck, it's not possible to verify the order in which
> frames are printed, and that dealing with line numb

Re: [lldb-dev] Using FileCheck in lldb inline tests

[Jason Molenda via lldb-dev]

> On Aug 14, 2018, at 6:39 PM, Zachary Turner  wrote:
> 
> Having bugs also makes the debugger harder to innovate in the future because 
> it’s, not having tests leads to having bugs, and sb api tests leads to not 
> having tests. At the end of the day, it doesn’t matter how stable the tests 
> are if there arent enough of them. There should be about 10x-20x as many 
> tests as there are currently, and that will simply never happen under the 
> current approach. If it means we need to have multiple different styles of 
> test, so be it. The problem we face right now has nothing to do with command 
> output changing, and in fact I don’t that we’ve *ever* had this problem. So 
> we should be focusing on problems we have, not problems we don’t have.


I think we've had this discussion many times over the years, so I apologize for 
not reiterating what I've said in the past.  I worked on gdb for a decade 
before this, where the entire testsuite was filecheck style tests based on 
gdb's output.  It made it easy for them to write, and after a couple decades of 
tests had accumulated, it became a nightmare to change or improve any of gdb's 
commands, we all avoided it like the plague because it was so onerous.  The 
tests themselves would accumulate more and more complicated regular expressions 
to handle different output that happened to be seen, so debugging WHY a given 
test was failing required an amazing amount of work.

Yes, lldb does not have these problems -- because we learned from our decades 
working on gdb, and did not repeat that mistake.  To be honest, lldb is such a 
young debugger - barely a decade old, depending on how you count it, that ANY 
testsuite approach would be fine at this point.  Add a couple more decades and 
we'd be back into the hole that gdb was in.  {I have not worked on gdb in over 
a decade, so I don't know how their testing methodology may be today}

It's always important to remember that lldb is first and foremost a debugger 
library.  It also includes a driver program, lldb, but it is designed as a 
library and it should be tested as a library.


> 
> Note that it is not strictly necessary for a test to check the debuggers 
> command output. There could be a different set of commands whose only purpose 
> is to print information for the purposes of debugging. One idea would be to 
> introduce the notion of a debugger object model, where you print various 
> aspects of the debuggers state with an object like syntax. For example,

This was the whole point of the lit tests, wasn't it?  To have a driver 
program, or driver programs, designed explicitly for filecheck, where the 
output IS API and can be relied on.  There hasn't been disagreement about this.

> 
> (lldb) p debugger.targets
> ~/foo (running, pid: 123)
> 
> (lldb) p debugger.targets[0].threads[0].frames[1]
> int main(int argc=3, char **argv=0x12345678) + 0x72
> 
> (lldb) p debugger.targets[0].threads[0].frames[1].params[0]
> int argc=3
> 
> (lldb) p debugger.targets[0].breakpoints
> [1] main.cpp:72
> 
> Etc. you can get arbitrarily granular and dxpose every detail of the 
> debuggers internal state this way, and the output is so simple that you never 
> have to worry about it changing.
> 
> That said, I think history has shown that limiting ourselves to sb api tests, 
> despite all the theoretical benefits, leads to insufficient test coverage. So 
> while it has benefits, it also has problems for which we need a better 
> solution
> On Tue, Aug 14, 2018 at 6:19 PM Jason Molenda via lldb-dev 
>  wrote:
> It's more verbose, and it does mean test writers need to learn the public 
> API, but it's also much more stable and debuggable in the future.  It's a 
> higher up front cost but we're paid back in being able to develop lldb more 
> quickly in the future, where our published API behaviors are being tested 
> directly, and the things that must not be broken.  The lldb driver's output 
> isn't a contract, and treating it like one makes the debugger harder to 
> innovate in the future.
> 
> It's also helpful when adding new features to ensure you've exposed the 
> feature through the API sufficiently.  The first thing I thought to try when 
> writing the example below was SBFrame::IsArtificial() (see 
> SBFrame::IsInlined()) which doesn't exist.  If a driver / IDE is going to 
> visually indicate artificial frames, they'll need that.
> 
> J
> 
> > On Aug 14, 2018, at 5:56 PM, Vedant Kumar  wrote:
> > 
> > It'd be easy to update FileCheck tests when changing the debugger (this 
> > happens all the time in clang/swift). OTOH, the verbosity of the python API 
> > means that fewer tests get written. I see a real need to make expressive 
> > tests easier to write.
> > 
> > vedant
> > 
> >> On Aug 14, 2018, at 5:38 PM, Jason Molenda  wrote:
> >> 
> >> I'd argue against this approach because it's exactly why the lit tests 
> >> don't run against the lldb driver -- they're hardcoding the output of the 
> >> lldb driver command

Re: [lldb-dev] Using FileCheck in lldb inline tests

[Zachary Turner via lldb-dev]

On Tue, Aug 14, 2018 at 6:58 PM Jason Molenda  wrote:

>
>
> > On Aug 14, 2018, at 6:39 PM, Zachary Turner  wrote:
> >
> > Having bugs also makes the debugger harder to innovate in the future
> because it’s, not having tests leads to having bugs, and sb api tests leads
> to not having te
>
> Yes, lldb does not have these problems -- because we learned from our
> decades working on gdb, and did not repeat that mistake.  To be honest,
> lldb is such a young debugger - barely a decade old, depending on how you
> count it, that ANY testsuite approach would be fine at this point.  Add a
> couple more decades and we'd be back into the hole that gdb was in.  {I
> have not worked on gdb in over a decade, so I don't know how their testing
> methodology may be today}

That doesn’t mean that the current approach is the final word.  As new
people come onto the project, new ideas come forth and we should entertain
them rather than deciding that all decisions are set in stone forever.

For example, the object model based approach I mentioned earlier would not
have any of the problems that you’ve described from gdb.  Just because one
set of problems has been solved doesn’t mean we should declare victory and
say there’s no point in trying to solve the remaining problems too.  And
right now, the problem is that we need to be coming up with a way to make
tests easier to write so that people will actually write them
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev