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

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

2018-08-20 Thread Александр Поляков via lldb-dev

Added Pavel to this thread.

Hi Pavel,

Do you know is it possible to enable lldb-server's logs in lldb or lldb-mi?

On Wed, Aug 15, 2018 at 8:34 PM Adrian Prantl  wrote:

>
>
> On Aug 15, 2018, at 10:31 AM, Александр Поляков 
> wrote:
>
> I built an lldb myself. As far as I remember, this error has been seen in
> swift's CI on machines running Linux. Adrian, could you correct me if I'm
> wrong?
>
>
> Yes, we have seen these test fail regularly, but I don't have any log
> files from the CI machines, so I can't confirm the the issue you are seeing
> was the same one that our bots encountered.
>
> -- 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

2018-08-15 Thread Adrian Prantl via lldb-dev

> On Aug 15, 2018, at 10:31 AM, Александр Поляков  
> wrote:
> 
> I built an lldb myself. As far as I remember, this error has been seen in 
> swift's CI on machines running Linux. Adrian, could you correct me if I'm 
> wrong?
> 

Yes, we have seen these test fail regularly, but I don't have any log files 
from the CI machines, so I can't confirm the the issue you are seeing was the 
same one that our bots encountered.

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

2018-08-15 Thread Александр Поляков via lldb-dev

I built an lldb myself. As far as I remember, this error has been seen in
swift's CI on machines running Linux. Adrian, could you correct me if I'm
wrong?

On Wed, Aug 15, 2018 at 8:02 PM  wrote:

> That definitely points to an issue with either your install or your system.
>
>
>
> Is that an lldb you built, or one you installed with apt-get?
>
>
>
> Turning on the lldb-server logs might help. Unfortunately, I forget how to
> do that . Pavel, do you remember?
>
>
>
> *From:* Александр Поляков 
> *Sent:* Tuesday, August 14, 2018 6:15 PM
> *To:* Ted Woodward 
> *Cc:* Adrian Prantl ; LLDB 
> *Subject:* Re: [lldb-dev] Failing LIT-based lldb-mi tests
>
>
>
> 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

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

2018-08-15 Thread via lldb-dev

That definitely points to an issue with either your install or your system.

 

Is that an lldb you built, or one you installed with apt-get?

 

Turning on the lldb-server logs might help. Unfortunately, I forget how to do 
that . Pavel, do you remember?

 

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

 

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 mailto:ted.woodw...@codeaurora.org> > 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 <mailto:apra...@apple.com>

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

2018-08-14 Thread Александр Поляков 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

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

2018-08-14 Thread 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

2018-08-14 Thread Александр Поляков 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:

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

2018-08-14 Thread 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

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

2018-08-14 Thread Александр Поляков 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] =

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

2018-08-14 Thread 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

2018-08-14 Thread Александр Поляков 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
>

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

2018-08-14 Thread 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

2018-08-14 Thread 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

2018-08-14 Thread Александр Поляков 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

2018-08-14 Thread 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

2018-08-14 Thread Александр Поляков 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

2018-08-13 Thread Adrian Prantl via lldb-dev

> 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

___
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

2018-08-13 Thread Александр Поляков via lldb-dev

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.

On Mon, Aug 13, 2018 at 11:18 PM Adrian Prantl  wrote:

>
>
> On Aug 13, 2018, at 11:54 AM, Александр Поляков 
> wrote:
>
> Oops, I made a mistake, I typed break-insert main. Here is the right
> output:
>
> build/bin/lldb-mi a.out
> (gdb)
> -file-exec-and-symbols "a.out"
> ^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"
> -exec-run
> ^running
> =thread-group-started,id="i1",pid="6406"
> (gdb)
> =thread-created,id="1",group-id="i1"
> =thread-selected,id="1"
> (gdb)
> =library-loaded,id="/lib/x86_64-linux-gnu/ld-2.23.so
> ",target-name="/lib/x86_64-linux-gnu/ld-2.23.so
> ",host-name="/lib/x86_64-linux-gnu/ld-2.23.so
> ",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/
> ld-2.23.so",loaded_addr="-",size="0"
> (gdb)
>
> =library-loaded,id="[vdso]",target-name="[vdso]",host-name="[vdso]",symbols-loaded="1",symbols-path="",loaded_addr="0x77ffa000",size="0"
> (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"
> (gdb)
> *running,thread-id="all"
> (gdb)
> (gdb)
>
> =library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/
> libc-2.23.so",loaded_addr="-",size="0"
> (gdb)
>
> =library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/
> libc-2.23.so",loaded_addr="-",size="0"
> -break-insert func
>
> ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00400514",func="func",file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="2",times="0",original-location="func"}
> (gdb)
>
> =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00400514",func="func",file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="2",times="0",original-location="func"}
> (gdb)
>
> =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00400514",func="func",file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="2",times="0",original-location="func"}
> (gdb)
> -exec-next
> ^error,msg="Resume timed out."
> (gdb)
> (gdb)
>
> *stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={level="0",addr="0x00400514",func="func",args=[],file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="2"},thread-id="1",stopped-threads="all"
>
>
> Do you get control back before the breakpoint is hit? If yes, should
> -exec-run block until the process stops (in synchronous mode)?
>
>
> (gdb)
> (gdb)
> *running,thread-id="all"
> (gdb)
> (gdb)
>
> *stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={level="0",addr="0x00400514",func="func",args=[],file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="2"},thread-id="1",stopped-threads="all"
> (gdb)
>
> On Mon, Aug 13, 2018 at 9:40 PM Александр Поляков 
> wrote:
>
>> Sure, this is the log with the typed commands:
>>
>> build/bin/lldb-mi a.out
>> (gdb)
>> -file-exec-and-symbols "a.out"
>> ^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"
>> -exec-run
>> ^running
>> =thread-group-started,id="i1",pid="4410"
>> (gdb)
>> =thread-created,id="1",group-id="i1"
>> =thread-selected,id="1"
>> (gdb)
>> =library-loaded,id="/lib/x86_64-linux-gnu/ld-2.23.so
>> ",target-name="/lib/x86_64-linux-gnu/ld-2.23.so
>> ",host-name="/lib/x86_64-linux-gnu/ld-2.23.so
>> ",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/
>> ld-2.23.so",loaded_addr="-",size="0"
>> (gdb)
>>
>> =library-loaded,id="[vdso]",target-name="[vdso]",host-name="[vdso]",symbols-loaded="1",symbols-path="",loaded_addr="0x77ffa000",size="0"
>> (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"
>> (gdb)
>> *running,thread-id="all"
>> (gdb)

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

2018-08-13 Thread Adrian Prantl via lldb-dev



> On Aug 13, 2018, at 11:54 AM, Александр Поляков  
> wrote:
> 
> Oops, I made a mistake, I typed break-insert main. Here is the right output:
> 
> build/bin/lldb-mi a.out 
> (gdb)
> -file-exec-and-symbols "a.out"
> ^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"
> -exec-run
> ^running
> =thread-group-started,id="i1",pid="6406"
> (gdb)
> =thread-created,id="1",group-id="i1"
> =thread-selected,id="1"
> (gdb)
> =library-loaded,id="/lib/x86_64-linux-gnu/ld-2.23.so 
> ",target-name="/lib/x86_64-linux-gnu/ld-2.23.so 
> ",host-name="/lib/x86_64-linux-gnu/ld-2.23.so 
> ",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/ld-2.23.so
>  ",loaded_addr="-",size="0"
> (gdb)
> =library-loaded,id="[vdso]",target-name="[vdso]",host-name="[vdso]",symbols-loaded="1",symbols-path="",loaded_addr="0x77ffa000",size="0"
> (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"
> (gdb)
> *running,thread-id="all"
> (gdb)
> (gdb)
> =library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/libc-2.23.so
>  ",loaded_addr="-",size="0"
> (gdb)
> =library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/libc-2.23.so
>  ",loaded_addr="-",size="0"
> -break-insert func
> ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00400514",func="func",file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="2",times="0",original-location="func"}
> (gdb)
> =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00400514",func="func",file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="2",times="0",original-location="func"}
> (gdb)
> =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00400514",func="func",file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="2",times="0",original-location="func"}
> (gdb)
> -exec-next
> ^error,msg="Resume timed out."
> (gdb)
> (gdb)
> *stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={level="0",addr="0x00400514",func="func",args=[],file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="2"},thread-id="1",stopped-threads="all"

Do you get control back before the breakpoint is hit? If yes, should -exec-run 
block until the process stops (in synchronous mode)?


> (gdb)
> (gdb)
> *running,thread-id="all"
> (gdb)
> (gdb)
> *stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={level="0",addr="0x00400514",func="func",args=[],file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="2"},thread-id="1",stopped-threads="all"
> (gdb)
> 
> On Mon, Aug 13, 2018 at 9:40 PM Александр Поляков  > wrote:
> Sure, this is the log with the typed commands:
> 
> build/bin/lldb-mi a.out 
> (gdb)
> -file-exec-and-symbols "a.out"
> ^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"
> -exec-run
> ^running
> =thread-group-started,id="i1",pid="4410"
> (gdb)
> =thread-created,id="1",group-id="i1"
> =thread-selected,id="1"
> (gdb)
> =library-loaded,id="/lib/x86_64-linux-gnu/ld-2.23.so 
> ",target-name="/lib/x86_64-linux-gnu/ld-2.23.so 
> ",host-name="/lib/x86_64-linux-gnu/ld-2.23.so 
> ",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/ld-2.23.so
>  ",loaded_addr="-",size="0"
> (gdb)
> =library-loaded,id="[vdso]",target-name="[vdso]",host-name="[vdso]",symbols-loaded="1",symbols-path="",loaded_addr="0x77ffa000",size="0"
> (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"
> (gdb)
> *running,thread-id="all"
> (gdb)
> (gdb)
>

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

2018-08-13 Thread Александр Поляков via lldb-dev

Sure, this is the log with the typed commands:

build/bin/lldb-mi a.out
(gdb)
-file-exec-and-symbols "a.out"
^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"
-exec-run
^running
=thread-group-started,id="i1",pid="4410"
(gdb)
=thread-created,id="1",group-id="i1"
=thread-selected,id="1"
(gdb)
=library-loaded,id="/lib/x86_64-linux-gnu/ld-2.23.so
",target-name="/lib/x86_64-linux-gnu/ld-2.23.so
",host-name="/lib/x86_64-linux-gnu/ld-2.23.so
",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/
ld-2.23.so",loaded_addr="-",size="0"
(gdb)
=library-loaded,id="[vdso]",target-name="[vdso]",host-name="[vdso]",symbols-loaded="1",symbols-path="",loaded_addr="0x77ffa000",size="0"
(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"
(gdb)
*running,thread-id="all"
(gdb)
(gdb)
=library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/
libc-2.23.so",loaded_addr="-",size="0"
(gdb)
=library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/
libc-2.23.so",loaded_addr="-",size="0"
-break-insert main
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0040052f",func="main",file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="7",times="0",original-location="main"}
(gdb)
=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0040052f",func="main",file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="7",times="0",original-location="main"}
(gdb)
=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0040052f",func="main",file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="7",times="0",original-location="main"}
(gdb)
-exec-next
^error,msg="Resume timed out."
(gdb)
(gdb)
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1",exit-code="0"
*stopped,reason="exited-normally"
(gdb)

No one of the commands isn't a blocking one, but I think that -exec-run
should be blocking.

On Mon, Aug 13, 2018 at 8:10 PM Adrian Prantl  wrote:

>
>
> > On Aug 11, 2018, at 3:58 AM, Александр Поляков 
> wrote:
> >
> > I reproduced the test you suggested and got following output:
> >
> > build/bin/lldb-mi --synchronous a.out <
> llvm/tools/lldb/lit/tools/lldb-mi/exec/lldb-mi-fail.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="0x000f",func="??",file="??",fullname="??/??",line="0",times="0",original-location="f"}
> > (gdb)
> >
> =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000f",func="??",file="??",fullname="??/??",line="0",times="0",original-location="f"}
> > (gdb)
> > ^done
> > (gdb)
> > ^running
> > =thread-group-started,id="i1",pid="5075"
> > (gdb)
> > =thread-created,id="1",group-id="i1"
> > =thread-selected,id="1"
> > (gdb)
> > =library-loaded,id="/lib/x86_64-linux-gnu/ld-2.23.so
> ",target-name="/lib/x86_64-linux-gnu/ld-2.23.so
> ",host-name="/lib/x86_64-linux-gnu/ld-2.23.so
> ",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/
> ld-2.23.so",loaded_addr="-",size="0"
> > (gdb)
> >
> =library-loaded,id="[vdso]",target-name="[vdso]",host-name="[vdso]",symbols-loaded="1",symbols-path="",loaded_addr="0x77ffa000",size="0"
> > (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"
> > (gdb)
> >
> =library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/
> libc-2.23.so",loaded_addr="-",size="0"
> > (gdb)
> >
>

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

2018-08-13 Thread Adrian Prantl via lldb-dev



> On Aug 11, 2018, at 3:58 AM, Александр Поляков  wrote:
> 
> I reproduced the test you suggested and got following output:
> 
> build/bin/lldb-mi --synchronous a.out < 
> llvm/tools/lldb/lit/tools/lldb-mi/exec/lldb-mi-fail.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="0x000f",func="??",file="??",fullname="??/??",line="0",times="0",original-location="f"}
> (gdb)
> =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000f",func="??",file="??",fullname="??/??",line="0",times="0",original-location="f"}
> (gdb)
> ^done
> (gdb)
> ^running
> =thread-group-started,id="i1",pid="5075"
> (gdb)
> =thread-created,id="1",group-id="i1"
> =thread-selected,id="1"
> (gdb)
> =library-loaded,id="/lib/x86_64-linux-gnu/ld-2.23.so",target-name="/lib/x86_64-linux-gnu/ld-2.23.so",host-name="/lib/x86_64-linux-gnu/ld-2.23.so",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/ld-2.23.so",loaded_addr="-",size="0"
> (gdb)
> =library-loaded,id="[vdso]",target-name="[vdso]",host-name="[vdso]",symbols-loaded="1",symbols-path="",loaded_addr="0x77ffa000",size="0"
> (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"
> (gdb)
> =library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/libc-2.23.so",loaded_addr="-",size="0"
> (gdb)
> =library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/libc-2.23.so",loaded_addr="-",size="0"
> (gdb)
> =thread-exited,id="1",group-id="i1"
> =thread-group-exited,id="i1",exit-code="0"
> *stopped,reason="exited-normally"
> (gdb)
> ^done
> (gdb)
> ^done
> (gdb)
> ^error,msg="Resume timed out."
> (gdb)
> ^done
> (gdb)
> 
> As a command that needs a breakpoint to be hit I chose the -exec-next 
> --thread 1. It's the same error which is seen on the bots.

Can you help me understand the order in which events happened in that log? I 
don't see the -exec-next command in the log. If you type in the commands 
manually, does it become obvious which ones are blocking and which ones aren't 
(but should be)?

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

2018-08-11 Thread Александр Поляков via lldb-dev

I reproduced the test you suggested and got following output:

build/bin/lldb-mi --synchronous a.out <
llvm/tools/lldb/lit/tools/lldb-mi/exec/lldb-mi-fail.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="0x000f",func="??",file="??",fullname="??/??",line="0",times="0",original-location="f"}
(gdb)
=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000f",func="??",file="??",fullname="??/??",line="0",times="0",original-location="f"}
(gdb)
^done
(gdb)
^running
=thread-group-started,id="i1",pid="5075"
(gdb)
=thread-created,id="1",group-id="i1"
=thread-selected,id="1"
(gdb)
=library-loaded,id="/lib/x86_64-linux-gnu/ld-2.23.so
",target-name="/lib/x86_64-linux-gnu/ld-2.23.so
",host-name="/lib/x86_64-linux-gnu/ld-2.23.so
",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/
ld-2.23.so",loaded_addr="-",size="0"
(gdb)
=library-loaded,id="[vdso]",target-name="[vdso]",host-name="[vdso]",symbols-loaded="1",symbols-path="",loaded_addr="0x77ffa000",size="0"
(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"
(gdb)
=library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/
libc-2.23.so",loaded_addr="-",size="0"
(gdb)
=library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/
libc-2.23.so",loaded_addr="-",size="0"
(gdb)
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1",exit-code="0"
*stopped,reason="exited-normally"
(gdb)
^done
(gdb)
^done
(gdb)
^error,msg="Resume timed out."
(gdb)
^done
(gdb)

As a command that needs a breakpoint to be hit I chose the -exec-next
--thread 1. It's the same error which is seen on the bots.

сб, 11 авг. 2018 г. в 6:27, Adrian Prantl :

> That't interesting. Where you able to simulate the error seen on the bots
> by inserting a sleep() unto the debugged program?
>
> -- adrian
>
> On Aug 10, 2018, at 5:06 PM, Александр Поляков 
> wrote:
>
> It seems that lldb-mi in such a situation just hangs:
>
> build/bin/lldb-mi --synchronous bash
> (gdb)
> -file-exec-and-symbols "bash"
> ^done
> (gdb)
>
> =library-loaded,id="/bin/bash",target-name="/bin/bash",host-name="/bin/bash",symbols-loaded="0",loaded_addr="-",size="0"
> -exec-run
> ^C^C
> exit
>
> It doesn't react to Ctrl+C and exit command.
>
> сб, 11 авг. 2018 г. в 2:54, Adrian Prantl :
>
>>
>>
>> On Aug 10, 2018, at 4:50 PM, Александр Поляков 
>> wrote:
>>
>> One important question: what do you mean talking about "block"? Does it
>> mean that SBTarget::Launch blocks the process and the user can't continue
>> working with this process until it stops?
>>
>>
>> Pretty much. The same way as the interactive (lldb) command line
>> interface behaves: You enter "run" and you won't get a prompt again until
>> the process stops. I'm imagining (but haven't verified) that synchronous
>> mode behaves like that.
>>
>> -- 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

2018-08-10 Thread Adrian Prantl via lldb-dev

That't interesting. Where you able to simulate the error seen on the bots by 
inserting a sleep() unto the debugged program?

-- adrian

> On Aug 10, 2018, at 5:06 PM, Александр Поляков  wrote:
> 
> It seems that lldb-mi in such a situation just hangs:
> 
> build/bin/lldb-mi --synchronous bash
> (gdb)
> -file-exec-and-symbols "bash"
> ^done
> (gdb)
> =library-loaded,id="/bin/bash",target-name="/bin/bash",host-name="/bin/bash",symbols-loaded="0",loaded_addr="-",size="0"
> -exec-run
> ^C^C
> exit
> 
> It doesn't react to Ctrl+C and exit command.
> 
> сб, 11 авг. 2018 г. в 2:54, Adrian Prantl  >:
> 
> 
>> On Aug 10, 2018, at 4:50 PM, Александр Поляков > > wrote:
>> 
>> One important question: what do you mean talking about "block"? Does it mean 
>> that SBTarget::Launch blocks the process and the user can't continue working 
>> with this process until it stops?
> 
> Pretty much. The same way as the interactive (lldb) command line interface 
> behaves: You enter "run" and you won't get a prompt again until the process 
> stops. I'm imagining (but haven't verified) that synchronous mode behaves 
> like that.
> 
> -- 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

2018-08-10 Thread Adrian Prantl via lldb-dev

> On Aug 10, 2018, at 4:50 PM, Александр Поляков  wrote:
> 
> One important question: what do you mean talking about "block"? Does it mean 
> that SBTarget::Launch blocks the process and the user can't continue working 
> with this process until it stops?

Pretty much. The same way as the interactive (lldb) command line interface 
behaves: You enter "run" and you won't get a prompt again until the process 
stops. I'm imagining (but haven't verified) that synchronous mode behaves like 
that.

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

2018-08-10 Thread Александр Поляков via lldb-dev

One important question: what do you mean talking about "block"? Does it
mean that SBTarget::Launch blocks the process and the user can't continue
working with this process until it stops?

сб, 11 авг. 2018 г. в 2:41, Adrian Prantl :

> I was wondering how this worked in the regular SBAPI that we use for all
> the "normal" python-based LLDB tests. The implementation of
> SBProcess::Continue() for example calls Process::Resume() or
> Process::ResumeSynchronous() depending on whether synchronous mode is set
> or not.
> It's not immediately obvious to me whether -exec-run should wait until the
> process stopped before returning or whether -exec-step should wait until
> the process stopped before executing.
>
> Based on a cursory reading of the sources it seems like SBTarget::Launch
> should block until the process stopped when it is in synchronous mode. Can
> you confirm this? If that is the case, can you figure out why -exec-run
> does not inherit this behavior?
>
> -- adrian
>
> > On Aug 10, 2018, at 4:27 PM, Александр Поляков 
> wrote:
> >
> > AFAIK, there is no mechanism in lldb-mi to distinguish a command that
> expects a frame, so we need to modify each command manually. Am I right?
> > If so, I found the Process::WaitForProcessToStop method which we can add
> to SB API and use in lldb-mi.
> >
> > сб, 11 авг. 2018 г. в 0:50, Adrian Prantl :
> > [adding lldb-dev back to the conversation]
> >
> > > On Aug 10, 2018, at 2:37 PM, Adrian Prantl  wrote:
> > >
> > >
> > >
> > >> On Aug 10, 2018, at 2:25 PM, Александр Поляков <
> polyakov@gmail.com> wrote:
> > >>
> > >> I didn't check this yet. lldb-mi already runs LIT test in the
> --synchronous mode and the tests keep failing.
> > >>
> > >
> > > Yes, that's why I said this:
> > >
> > >
> > >>> пт, 10 авг. 2018 г. в 23:57, Adrian Prantl :
> > >>>
> > >>> Before we continue to discuss -wait-for-breakpoint; where you
> actually able to verify my suspicion that that is what is happening on the
> bots? Fred suggested to me offline today that in synchronous mode, perhaps
> -exec-* should be waiting for the process to be stopped, which would also
> sound like a reasonable and less invasive solution to the problem.
> > >>>
> > >>
> > >
> > > Instead of adding a new command to wait for the process to be stopped
> we might be able to just wait for the process to be stopped if in
> synchronous mode and we are running any commands that expect a frame (such
> as -exec-*).
> > >
> > > -- 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

2018-08-10 Thread Adrian Prantl via lldb-dev

I was wondering how this worked in the regular SBAPI that we use for all the 
"normal" python-based LLDB tests. The implementation of SBProcess::Continue() 
for example calls Process::Resume() or Process::ResumeSynchronous() depending 
on whether synchronous mode is set or not.
It's not immediately obvious to me whether -exec-run should wait until the 
process stopped before returning or whether -exec-step should wait until the 
process stopped before executing.

Based on a cursory reading of the sources it seems like SBTarget::Launch should 
block until the process stopped when it is in synchronous mode. Can you confirm 
this? If that is the case, can you figure out why -exec-run does not inherit 
this behavior?

-- adrian

> On Aug 10, 2018, at 4:27 PM, Александр Поляков  wrote:
> 
> AFAIK, there is no mechanism in lldb-mi to distinguish a command that expects 
> a frame, so we need to modify each command manually. Am I right?
> If so, I found the Process::WaitForProcessToStop method which we can add to 
> SB API and use in lldb-mi.
> 
> сб, 11 авг. 2018 г. в 0:50, Adrian Prantl :
> [adding lldb-dev back to the conversation]
> 
> > On Aug 10, 2018, at 2:37 PM, Adrian Prantl  wrote:
> > 
> > 
> > 
> >> On Aug 10, 2018, at 2:25 PM, Александр Поляков  
> >> wrote:
> >> 
> >> I didn't check this yet. lldb-mi already runs LIT test in the 
> >> --synchronous mode and the tests keep failing.
> >> 
> > 
> > Yes, that's why I said this:
> > 
> > 
> >>> пт, 10 авг. 2018 г. в 23:57, Adrian Prantl :
> >>> 
> >>> Before we continue to discuss -wait-for-breakpoint; where you actually 
> >>> able to verify my suspicion that that is what is happening on the bots? 
> >>> Fred suggested to me offline today that in synchronous mode, perhaps 
> >>> -exec-* should be waiting for the process to be stopped, which would also 
> >>> sound like a reasonable and less invasive solution to the problem.
> >>> 
> >> 
> > 
> > Instead of adding a new command to wait for the process to be stopped we 
> > might be able to just wait for the process to be stopped if in synchronous 
> > mode and we are running any commands that expect a frame (such as -exec-*).
> > 
> > -- 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

2018-08-10 Thread Александр Поляков via lldb-dev

AFAIK, there is no mechanism in lldb-mi to distinguish a command that
expects a frame, so we need to modify each command manually. Am I right?
If so, I found the Process::WaitForProcessToStop method which we can add to
SB API and use in lldb-mi.

сб, 11 авг. 2018 г. в 0:50, Adrian Prantl :

> [adding lldb-dev back to the conversation]
>
> > On Aug 10, 2018, at 2:37 PM, Adrian Prantl  wrote:
> >
> >
> >
> >> On Aug 10, 2018, at 2:25 PM, Александр Поляков 
> wrote:
> >>
> >> I didn't check this yet. lldb-mi already runs LIT test in the
> --synchronous mode and the tests keep failing.
> >>
> >
> > Yes, that's why I said this:
> >
> >
> >>> пт, 10 авг. 2018 г. в 23:57, Adrian Prantl :
> >>>
> >>> Before we continue to discuss -wait-for-breakpoint; where you actually
> able to verify my suspicion that that is what is happening on the bots?
> Fred suggested to me offline today that in synchronous mode, perhaps
> -exec-* should be waiting for the process to be stopped, which would also
> sound like a reasonable and less invasive solution to the problem.
> >>>
> >>
> >
> > Instead of adding a new command to wait for the process to be stopped we
> might be able to just wait for the process to be stopped if in synchronous
> mode and we are running any commands that expect a frame (such as -exec-*).
> >
> > -- 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

2018-08-10 Thread Adrian Prantl via lldb-dev

[adding lldb-dev back to the conversation]

> On Aug 10, 2018, at 2:37 PM, Adrian Prantl  wrote:
> 
> 
> 
>> On Aug 10, 2018, at 2:25 PM, Александр Поляков  
>> wrote:
>> 
>> I didn't check this yet. lldb-mi already runs LIT test in the --synchronous 
>> mode and the tests keep failing.
>> 
> 
> Yes, that's why I said this:
> 
> 
>>> пт, 10 авг. 2018 г. в 23:57, Adrian Prantl :
>>> 
>>> Before we continue to discuss -wait-for-breakpoint; where you actually able 
>>> to verify my suspicion that that is what is happening on the bots? Fred 
>>> suggested to me offline today that in synchronous mode, perhaps -exec-* 
>>> should be waiting for the process to be stopped, which would also sound 
>>> like a reasonable and less invasive solution to the problem.
>>> 
>> 
> 
> Instead of adding a new command to wait for the process to be stopped we 
> might be able to just wait for the process to be stopped if in synchronous 
> mode and we are running any commands that expect a frame (such as -exec-*).
> 
> -- 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

2018-08-10 Thread Adrian Prantl via lldb-dev



> On Aug 10, 2018, at 11:13 AM, Adrian Prantl via lldb-dev 
>  wrote:
> 
> [+lldb-dev, since this affects all bots equally]
> 
> Alexander, it looks like there is a race condition in some of the LIT-based 
> lldb-mi tests.
> 
> For example, exec-next.test:
> 
>  # Test lldb-mi -exec-next command.
> 
>  # Check that we have a valid target created via '%lldbmi %t'.
>  # CHECK: ^done
> 
>  -break-insert main
>  # CHECK: ^done,bkpt={number="1"
> 
>  -exec-run
>  # CHECK: ^running
>  # CHECK: *stopped,reason="breakpoint-hit"
> 
>  -exec-next --thread 0
>  # Check that exec-next can process the case of invalid thread ID.
>  # CHECK: ^error,msg="Command 'exec-next'. Thread ID invalid"
> 
>  ...
> 
> Here we are not actually waiting for the breakpoint to be hit. Synchronous 
> mode ensures that the lldb-mi driver waits for each command to be completed, 
> but that only means that -exec-run only returns after the process has been 
> launched and does not include waiting for the program to actually hit a 
> breakpoint. So if the program runs very slowly (such as often happens on a 
> very busy bot), the -exec-next and subsequent commands are scheduled before 
> the breakpoint is hit. In order to fix this we either need to move any tests 
> that schedule commands after hitting breakpoints back to Python, or we need 
> to add a new -wait-for-breakpoint MI command for testing only to force a 
> synchronization point.

In order to test my hypothesis, you could set the breakpoint in a different 
function than main and insert a sleep() into the program to simulate the 
condition on the bots, i.e.:

  void foo() {
// actual test code below
...
  }

  int main(int argc, char ** argv) {
sleep(10);
foo();
  }

and in the test:

  # instead of main:
  -break-insert foo
  # and then :-)
  -some-command-that-would-fail-if-executed-before-breakpoint-is-hit

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

29 matches

Site Navigation

Mail list logo

Footer information