Since lldb-server only supports running on a limited set of host operating systems it is hard for me to diagnose the issue completely, but I suspect the problem is caused by the fact that the new listening code can open more than one socket, and TCPSocket::GetLocalPortNumber() may be misbehaving.
I'm unlikely to have time to investigate further until next week, but it should be possible to craft a unit test that verifies that GetLocalPortNumber() returns non-zero on a socket that is listening before a connection is established. That might reproduce the issue in a more easy to debug environment. -Chris > On Aug 25, 2017, at 7:38 AM, Ramana via lldb-dev <lldb-dev@lists.llvm.org> > wrote: > > Ted, Greg, > > I have built lldb tools @r300578 and the lldb-server is returning the > proper port number to lldb client and the remote debugging is working. > I have given the lldb-server log at the bottom of my reply. > > So, it looks https://reviews.llvm.org/rL300579 (Update LLDB Host to > support IPv6 over TCP) is causing the issue. > >> Ramana, can you stick in a log message to print port_cstr? I suspect it's >> actually getting 0 back from lldb-server, which would tell us the error is >> in the server code, not the client code. > > Ted, I did that and actually the pipe read is returning zero port > number. So definitely the issue is on the server side. > > GDBRemoteCommunication::StartDebugserverProcess() port_cstr > before socket pipe read > GDBRemoteCommunication::StartDebugserverProcess() port_cstr after > socket pipe read > > >> Ted's comments are correct and I am guessing we will find the "lldb-server >> gdb-server" is not doing the right thing and it isn't returning the >> correctly bound port. >> >> When we are doing remote stuff we must use TCP so there should be >> lldb-server should be opening a TCP socket, binding, listening and accepting >> a connection from the remote LLDB. >> >> Greg > > Greg, thanks for the comments. Are you saying I should check what is > happening on the TCP socket side? How do I do it other than walking > through the code? > > > root@arria5:~# /mnt/var/patch_bins/binaries/bin/lldb-server platform > --log-file Ramana/remote.log --log-channels "gdb-remote process" > --server --listen *:1400 > Connection established. > error: lost connection > lldb-server exiting... > ^C > root@arria5:~# /mnt/var/patch_bins/binaries/bin/lldb --version > lldb version 5.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk > revision 300578) > clang revision 300578 > llvm revision 300578 > root@arria5:~# cat Ramana/remote.log > GDBRemoteCommunication::StartDebugserverProcess(url=tcp://10.10.12.3:0, > port=0) > GDBRemoteCommunication::StartDebugserverProcess() found gdb-remote > stub exe '/mnt/var/patch_bins/binaries/bin/lldb-server' > launch info for gdb-remote stub: > Executable: lldb-server > Triple: *-*-* > Arguments: > argv[0]="/mnt/var/patch_bins/binaries/bin/lldb-server" > argv[1]="gdbserver" > argv[2]="tcp://10.10.12.3:0" > argv[3]="--native-regs" > argv[4]="--pipe" > argv[5]="7" > argv[6]=NULL > > Environment: > env[0]="XDG_SESSION_ID=c7" > env[1]="TERM=xterm-256color" > env[2]="SHELL=/bin/sh" > env[3]="SSH_CLIENT=172.16.16.51 40072 22" > env[4]="SSH_TTY=/dev/pts/0" > env[5]="USER=root" > env[6]="MAIL=/var/mail/root" > env[7]="PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin" > env[8]="PWD=/home/root" > env[9]="EDITOR=vi" > env[10]="PS1=\u@\h:\w\$ " > env[11]="SHLVL=1" > env[12]="HOME=/home/root" > env[13]="LOGNAME=root" > env[14]="SSH_CONNECTION=172.16.16.51 40072 10.10.2.4 22" > env[15]="XDG_RUNTIME_DIR=/run/user/0" > env[16]="_=/mnt/var/patch_bins/binaries/bin/lldb-server" > env[17]=NULL > > GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 48039 > port > > > Regards, > Ramana > > On Thu, Aug 24, 2017 at 10:10 PM, Greg Clayton <clayb...@gmail.com> wrote: >> >>> On Aug 24, 2017, at 8:33 AM, Ted Woodward <ted.woodw...@codeaurora.org> >>> wrote: >>> >>> The lldb-server launch line looks ok; it should take the port 0 arg and get >>> a port from the OS. >>> lldb is getting the port back from lldb-server in 4.0.1, as seen here: >>> >>>> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens >>>> 56543 port >>> >>> But for 5.0.0 we see it fail the debugserver launch, and get: >>> >>>> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 0 >>>> port >>> >>> That log message comes right after the pipe read, which succeeds because >>> error.Success() is true: >>> >>> // Read port from pipe with 10 second timeout. >>> error = socket_pipe.ReadWithTimeout( >>> port_cstr, num_bytes, std::chrono::seconds{10}, num_bytes); >>> if (error.Success() && (port != nullptr)) { >>> assert(num_bytes > 0 && port_cstr[num_bytes - 1] == '\0'); >>> uint16_t child_port = StringConvert::ToUInt32(port_cstr, 0); >>> if (*port == 0 || *port == child_port) { >>> *port = child_port; >>> if (log) >>> log->Printf("GDBRemoteCommunication::%s() " >>> "debugserver listens %u port", >>> __FUNCTION__, *port); >>> >>> As an aside, I don't like that assert - if we get garbage back from the >>> pipe, we should error out, not take down lldb. >> >> The assert should be removed and the code should work correctly without the >> assert. >> >>> Another aside, the definition of port_cstr is odd: >>> char port_cstr[PATH_MAX] = {0}; >>> port_cstr[0] = '\0'; >>> The size is way to big - max port number is 65535, so we don't need >>> PATH_MAX bytes. And 2 assignments to make it a null string? >>> >>> >>> Ramana, can you stick in a log message to print port_cstr? I suspect it's >>> actually getting 0 back from lldb-server, which would tell us the error is >>> in the server code, not the client code. >>> >> >> With the following args: >> >> argv[0]="/mnt/var/binaries/arm_release/bin/lldb-server" >> argv[1]="gdbserver" >> argv[2]="tcp://10.10.12.3:0" >> argv[3]="--native-regs" >> argv[4]="--pipe" >> argv[5]="7" >> argv[6]=NULL >> >> lldb-server should bind to port 0, figure out the port, and write the port >> number into the file descriptor 7 ("--pipe 7" argument) to let the other >> side know what port to report back to the remote LLDB. The reply to the >> qLaunchGDBServer packet should then contain this valid port number. >> >> Ted's comments are correct and I am guessing we will find the "lldb-server >> gdb-server" is not doing the right thing and it isn't returning the >> correctly bound port. >> >> When we are doing remote stuff we must use TCP so there should be >> lldb-server should be opening a TCP socket, binding, listening and accepting >> a connection from the remote LLDB. >> >> Greg >> >> >> >>> Ted >>> >>> -- >>> Qualcomm Innovation Center, Inc. >>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a >>> Linux Foundation Collaborative Project >>> >>>> -----Original Message----- >>>> From: Ramana [mailto:ramana.venka...@gmail.com] >>>> Sent: Thursday, August 24, 2017 4:00 AM >>>> To: Ted Woodward <ted.woodw...@codeaurora.org> >>>> Cc: Greg Clayton <clayb...@gmail.com>; Hans Wennborg >>>> <h...@chromium.org>; lldb-dev@lists.llvm.org >>>> Subject: Re: [lldb-dev] Remote debugging ARM target from x86 host >>>> >>>> Greg, Ted >>>> >>>> Thanks for your comments. >>>> >>>> On Thu, Aug 24, 2017 at 12:01 AM, Ted Woodward >>>> <ted.woodw...@codeaurora.org> wrote: >>>>> >>>>> What should be happening is Handle_qLaunchGDBServer calls >>>> LaunchGDBServer with a port of UINT16_MAX, which tells it to use a port in >>>> its >>>> port list. It shouldn't have a port list, so should return 0. >>>> LaunchGDBServer calls >>>> StartDebugServerProcess with a port of 0 in the url. >>>> StartDebugServerProcess >>>> launches the gdbserver with a named pipe, and reads the actual port from >>>> the >>>> pipe. >>>> >>>> Yes, the port list is empty unless --(min/max)-gdbserver-port is specified >>>> and >>>> the gdbserver reads port number from the named pipe which in the failing >>>> case >>>> is zero. >>>> >>>>> I suggest turning on more logging - specifically, "gdb-remote process". >>>>> That's >>>> the channel used in StartDebugServerProcess. >>>>> >>>> >>>> In fact I have given the relevant log line of "gdb-remote process" in the >>>> bug >>>> details reporting port zero. Anyhow, the full log of "gdb-remote process" >>>> for >>>> both lldb v4.0.1 and v5.0.0 is given at the bottom of my reply. >>>> >>>> I thought https://reviews.llvm.org/rL295947 (Ensure lldb-server waits for >>>> child >>>> debug servers to start up when passing them) got something to do with this >>>> bug >>>> but both reversing >>>> >>>> if (pass_comm_fd == -1) { at >>>> source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:1086 >>>> >>>> to original >>>> >>>> if (pass_comm_fd == -1 && ((port != nullptr && *port == 0) || port == >>>> nullptr)) { >>>> >>>> and >>>> >>>> increasing the time out to 30 sec from 10 sec in >>>> socket_pipe.ReadWithTimeout() at >>>> source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:1255 >>>> >>>> did not solve the issue. >>>> >>>> By the way, the remote debugging of x86 (linux) from x86 (linux) with lldb >>>> v5.0.0 (but works with v4.0.1) also fails with assertion >>>> >>>> assert(num_bytes > 0 && port_cstr[num_bytes - 1] == '\0'); at >>>> source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:1258 >>>> >>>> due to the reason that socket_pipe.ReadWithTimeout() could not successfully >>>> read the port number from the named pipe. >>>> >>>> Based on the above, though I am not sure, the other patch I could think of >>>> having an effect on this bug is >>>> https://reviews.llvm.org/rL300579 (Update LLDB Host to support IPv6 over >>>> TCP) >>>> which changed the socket implementation. >>>> >>>> >>>> lldb-server log for "gdb-remote process" with lldb v4.0.1 (passing case) >>>> >>>> GDBRemoteCommunication::StartDebugserverProcess(url=tcp://10.10.12.3:0, >>>> port=0) >>>> GDBRemoteCommunication::StartDebugserverProcess() found gdb-remote stub >>>> exe '/mnt/var/binaries/arm_release/bin/lldb-server' >>>> launch info for gdb-remote stub: >>>> Executable: lldb-server >>>> Triple: *-*-* >>>> Arguments: >>>> argv[0]="/mnt/var/binaries/arm_release/bin/lldb-server" >>>> argv[1]="gdbserver" >>>> argv[2]="tcp://10.10.12.3:0" >>>> argv[3]="--native-regs" >>>> argv[4]="--pipe" >>>> argv[5]="7" >>>> argv[6]=NULL >>>> >>>> Environment: >>>> env[0]="XDG_SESSION_ID=c3" >>>> env[1]="TERM=xterm-256color" >>>> env[2]="SHELL=/bin/sh" >>>> env[3]="SSH_CLIENT=10.10.33.99 53542 22" >>>> env[4]="SSH_TTY=/dev/pts/0" >>>> env[5]="USER=root" >>>> env[6]="MAIL=/var/mail/root" >>>> env[7]="PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin" >>>> env[8]="PWD=/home/root" >>>> env[9]="EDITOR=vi" >>>> env[10]="PS1=\u@\h:\w\$ " >>>> env[11]="SHLVL=1" >>>> env[12]="HOME=/home/root" >>>> env[13]="LOGNAME=root" >>>> env[14]="SSH_CONNECTION=10.10.33.99 53542 10.10.2.4 22" >>>> env[15]="XDG_RUNTIME_DIR=/run/user/0" >>>> env[16]="_=/mnt/var/binaries/arm_release/bin/lldb-server" >>>> env[17]=NULL >>>> >>>> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens >>>> 56543 port >>>> >>>> >>>> lldb-server log for "gdb-remote process" with lldb v5.0.0 (failing case) >>>> >>>> >>>> GDBRemoteCommunication::StartDebugserverProcess(url=tcp://10.10.12.3:0, >>>> port=0) >>>> GDBRemoteCommunication::StartDebugserverProcess() found gdb-remote stub >>>> exe '/mnt/var/binaries/arm_v5.0_orig/bin/lldb-server' >>>> launch info for gdb-remote stub: >>>> Executable: lldb-server >>>> Triple: *-*-* >>>> Arguments: >>>> argv[0]="/mnt/var/binaries/arm_v5.0_orig/bin/lldb-server" >>>> argv[1]="gdbserver" >>>> argv[2]="tcp://10.10.12.3:0" >>>> argv[3]="--native-regs" >>>> argv[4]="--pipe" >>>> argv[5]="7" >>>> argv[6]=NULL >>>> >>>> Environment: >>>> env[0]="XDG_SESSION_ID=c3" >>>> env[1]="TERM=xterm-256color" >>>> env[2]="SHELL=/bin/sh" >>>> env[3]="SSH_CLIENT=10.10.33.99 53542 22" >>>> env[4]="SSH_TTY=/dev/pts/0" >>>> env[5]="USER=root" >>>> env[6]="MAIL=/var/mail/root" >>>> env[7]="PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin" >>>> env[8]="PWD=/home/root" >>>> env[9]="EDITOR=vi" >>>> env[10]="PS1=\u@\h:\w\$ " >>>> env[11]="SHLVL=1" >>>> env[12]="HOME=/home/root" >>>> env[13]="LOGNAME=root" >>>> env[14]="SSH_CONNECTION=10.10.33.99 53542 10.10.2.4 22" >>>> env[15]="XDG_RUNTIME_DIR=/run/user/0" >>>> env[16]="_=/mnt/var/binaries/arm_v5.0_orig/bin/lldb-server" >>>> env[17]=NULL >>>> >>>> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 0 >>>> port >>>> >>>> >>>> Thanks, >>>> Ramana >>>> >>>>> -- >>>>> Qualcomm Innovation Center, Inc. >>>>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, >>>>> a Linux Foundation Collaborative Project >>>>> >>>>>> -----Original Message----- >>>>>> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of >>>>>> Greg Clayton via lldb-dev >>>>>> Sent: Wednesday, August 23, 2017 12:45 PM >>>>>> To: Hans Wennborg <h...@chromium.org> >>>>>> Cc: Ramana <ramana.venka...@gmail.com>; LLDB Dev <lldb- >>>>>> d...@lists.llvm.org> >>>>>> Subject: Re: [lldb-dev] Remote debugging ARM target from x86 host >>>>>> >>>>>> Port zero should never be returned as a valid port. We do bind to >>>>>> port zero just so we don't try and pick a port at random just to find >>>>>> it is being used. When we bind to port 9, we must find the actual >>>>>> port we bound to and return that. Seems something has gone wrong with >>>>>> the code that discovers the port that was actually bound and is not >>>>>> reporting >>>> that back correctly. >>>>>> >>>>>> >>>>>> Should be straight forward to do by debugging the function >>>>>> GDBRemoteCommunicationServerPlatform::Handle_qLaunchGDBServer(...) >>>> in >>>>>> GDBRemoteCommunicationServerPlatform.cpp and see what is going on >>>> and >>>>>> why it is returning 0 as the port. >>>>>> >>>>>> Greg >>>>>> >>>>>>> On Aug 23, 2017, at 9:44 AM, Hans Wennborg via lldb-dev <lldb- >>>>>> d...@lists.llvm.org> wrote: >>>>>>> >>>>>>> This was marked as an lldb 5.0.0 release blocker since it's a >>>>>>> regression from 4.0.1: https://bugs.llvm.org/show_bug.cgi?id=34183 >>>>>>> >>>>>>> lldb-dev: Is there any interest in fixing this bug? >>>>>>> >>>>>>> On Fri, Aug 4, 2017 at 10:13 PM, Ramana via lldb-dev >>>>>>> <lldb-dev@lists.llvm.org> wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I am trying to remote debug ARM (linux) target from x86 (linux) >>>>>>>> host and I am getting the following error while trying to launch a >>>>>>>> process. >>>>>>>> The local debugging on ARM works. >>>>>>>> >>>>>>>> error: connect remote failed (invalid host:port specification: >>>>>>>> '10.10.2.3') >>>>>>>> error: process launch failed: invalid host:port specification: >>>>>>>> '10.10.2.3' >>>>>>>> >>>>>>>> It appears the above error is because the gdb-remote is returning >>>>>>>> the communication port as zero. >>>>>>>> >>>>>>>> < 36> send packet: $qLaunchGDBServer;host:svrlin249;#bb >>>>>>>> < 19> read packet: $pid:298;port:0;#bf >>>>>>>> >>>>>>>> What are the possible reasons for the above behavior from >>>>>>>> gdb-remote and how I could resolve this? >>>>>>>> >>>>>>>> If it helps, below is the full log. >>>>>>>> >>>>>>>> (lldb) log enable lldb comm >>>>>>>> (lldb) log enable gdb-remote packets >>>>>>>> (lldb) platform select remote-linux >>>>>>>> Platform: remote-linux >>>>>>>> Connected: no >>>>>>>> (lldb) platform connect connect://10.10.2.3:500 >>>>>>>> 0x915bd78 Communication::Communication (name = gdb-remote.client) >>>>>>>> 0x915bd78 Communication::Disconnect () >>>>>>>> 0x915bd78 Communication::Disconnect () >>>>>>>> 0x915bd78 Communication::Connect (url = connect://10.10.2.3:500) >>>>>>>> Socket::TcpConnect (host/port = 10.10.2.3:500) TCPSocket::Connect >>>>>>>> (host/port = 10.10.2.3:500) >>>>>>>> 0x915bd78 Communication::Write (src = 0xbfcb7433, src_len = 1) >>>>>>>> connection = 0x915f578 >>>>>>>> 0x915f608 Socket::Write() (socket = 7, src = 0xbfcb7433, src_len = >>>>>>>> 1, flags = 0) => 1 (error = (null)) >>>>>>>> < 1> send packet: + >>>>>>>> this = 0x0915BD78, dst = 0xBFCB53EC, dst_len = 8192, timeout = >>>>>>>> 10000 us, connection = 0x0915F578 >>>>>>>> 0x915bd78 Communication::Write (src = 0x916022c, src_len = 19) >>>>>>>> connection = 0x915f578 >>>>>>>> 0x915f608 Socket::Write() (socket = 7, src = 0x916022c, src_len = >>>>>>>> 19, flags = 0) => 19 (error = (null)) >>>>>>>> history[1] tid=0x7cbf < 1> send packet: + >>>>>>>> < 19> send packet: $QStartNoAckMode#b0 this = 0x0915BD78, dst = >>>>>>>> 0xBFCB51AC, dst_len = 8192, timeout = 6000000 us, connection = >>>>>>>> 0x0915F578 >>>>>>>> 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb51ac, src_len = >>>>>>>> 7, flags = 0) => 7 (error = (null)) >>>>>>>> < 1> read packet: + >>>>>>>> < 6> read packet: $OK#9a >>>>>>>> 0x915bd78 Communication::Write (src = 0xbfcb50f3, src_len = 1) >>>>>>>> connection = 0x915f578 >>>>>>>> 0x915f608 Socket::Write() (socket = 7, src = 0xbfcb50f3, src_len = >>>>>>>> 1, flags = 0) => 1 (error = (null)) >>>>>>>> < 1> send packet: + >>>>>>>> 0x915bd78 Communication::Write (src = 0x9161ff4, src_len = 13) >>>>>>>> connection = 0x915f578 >>>>>>>> 0x915f608 Socket::Write() (socket = 7, src = 0x9161ff4, src_len = >>>>>>>> 13, flags = 0) => 13 (error = (null)) < 13> send packet: >>>>>>>> $qHostInfo#9b this = 0x0915BD78, dst = 0xBFCB510C, dst_len = 8192, >>>>>>>> timeout = >>>>>>>> 1000000 us, connection = 0x0915F578 >>>>>>>> 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb510c, src_len = >>>>>>>> 316, flags = 0) => 316 (error = (null)) < 316> read packet: >>>>>>>> >>>>>> >>>> $triple:61726d2d2d6c696e75782d676e75656162696866;ptrsize:4;watchpoint >>>>>>>> _exceptions_received:before;endian:little;os_version:3.10.31;os_bu >>>>>>>> ild >>>>>>>> >>>>>> >>>> :332e31302e33312d6c7473692d30323836312d6738303161343066;os_kernel:2 >>>>>> 33 >>>>>>>> >>>>>> >>>> 520534d5020467269204d61792031332031353a35383a3232204953542032303 >>>>>> 136;h >>>>>>>> ostname:736f >>>>>>>> 63667067615f617272696135;#0a >>>>>>>> 0x915bd78 Communication::Write (src = 0x915fe9c, src_len = 18) >>>>>>>> connection = 0x915f578 >>>>>>>> 0x915f608 Socket::Write() (socket = 7, src = 0x915fe9c, src_len = >>>>>>>> 18, flags = 0) => 18 (error = (null)) < 18> send packet: >>>>>>>> $qGetWorkingDir#91 this = 0x0915BD78, dst = 0xBFCB50FC, dst_len = >>>>>>>> 8192, timeout = 1000000 us, connection = 0x0915F578 >>>>>>>> 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb50fc, src_len = >>>>>>>> 24, flags = 0) => 24 (error = (null)) < 24> read packet: >>>>>>>> $2f686f6d652f726f6f74#4b >>>>>>>> 0x915bd78 Communication::Write (src = 0x915fe9c, src_len = 19) >>>>>>>> connection = 0x915f578 >>>>>>>> 0x915f608 Socket::Write() (socket = 7, src = 0x915fe9c, src_len = >>>>>>>> 19, flags = 0) => 19 (error = (null)) < 19> send packet: >>>>>>>> $qQueryGDBServer#cb this = 0x0915BD78, dst = 0xBFCB531C, dst_len = >>>>>>>> 8192, timeout = 1000000 us, connection = 0x0915F578 >>>>>>>> 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb531c, src_len = >>>>>>>> 7, flags = 0) => 7 (error = (null)) >>>>>>>> < 7> read packet: $E04#a9 >>>>>>>> Platform: remote-linux >>>>>>>> Triple: arm-*-linux-gnueabihf >>>>>>>> OS Version: 3.10.31 (3.10.31-ltsi-02861-g801a40f) >>>>>>>> Kernel: #5 SMP Fri May 13 15:58:22 IST 2016 >>>>>>>> Hostname: socfpga_arria5 >>>>>>>> Connected: yes >>>>>>>> WorkingDir: /home/root >>>>>>>> (lldb) file main >>>>>>>> 0x915bd78 Communication::Write (src = 0x91638fc, src_len = 137) >>>>>>>> connection = 0x915f578 >>>>>>>> 0x915f608 Socket::Write() (socket = 7, src = 0x91638fc, src_len = >>>>>>>> 137, flags = 0) => 137 (error = (null)) < 137> send packet: >>>>>>>> >>>>>> >>>> $qModuleInfo:2f686f6d652f72616d616e616e2f776f726b5f726f6f742f546f545f >>>>>>>> >>>>>> >>>> 6c6c64622f74657374732f6d61696e;61726d2d2d6c696e75782d656162696866# >>>>>> f1 >>>>>>>> this = 0x0915BD78, dst = 0xBFCB172C, dst_len = 8192, timeout = >>>>>>>> 1000000 us, connection = 0x0915F578 >>>>>>>> 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb172c, src_len = >>>>>>>> 7, flags = 0) => 7 (error = (null)) >>>>>>>> < 7> read packet: $E03#a8 >>>>>>>> Current executable set to 'main' (arm). >>>>>>>> (lldb) b main >>>>>>>> Breakpoint 1: where = main`main + 4 at main.c:4, address = >>>>>>>> 0x000104a0 >>>>>>>> (lldb) run >>>>>>>> 0x915bd78 Communication::Write (src = 0x917bae4, src_len = 36) >>>>>>>> connection = 0x915f578 >>>>>>>> 0x915f608 Socket::Write() (socket = 7, src = 0x917bae4, src_len = >>>>>>>> 36, flags = 0) => 36 (error = (null)) < 36> send packet: >>>>>>>> $qLaunchGDBServer;host:svrlin249;#bb >>>>>>>> this = 0x0915BD78, dst = 0xBFCB4FDC, dst_len = 8192, timeout = >>>>>>>> 10000000 us, connection = 0x0915F578 >>>>>>>> 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb4fdc, src_len = >>>>>>>> 19, flags = 0) => 19 (error = (null)) < 19> read packet: >>>>>>>> $pid:298;port:0;#bf >>>>>>>> 0x92b0a84 Communication::Communication (name = process.stdio) >>>>>>>> 0x92b0d78 Communication::Communication (name = gdb-remote.client) >>>>>>>> 0x92b0a84 Communication::Disconnect () Socket::TcpConnect >>>>>>>> (host/port = 10.10.2.3) TCPSocket::Connect (host/port = 10.10.2.3) >>>>>>>> Socket::TcpConnect (host/port = 10.10.2.3) TCPSocket::Connect >>>>>>>> (host/port = 10.10.2.3) Socket::TcpConnect (host/port = 10.10.2.3) >>>>>>>> TCPSocket::Connect (host/port = 10.10.2.3) Socket::TcpConnect >>>>>>>> (host/port = 10.10.2.3) TCPSocket::Connect (host/port = 10.10.2.3) >>>>>>>> Socket::TcpConnect (host/port = 10.10.2.3) TCPSocket::Connect >>>>>>>> (host/port = 10.10.2.3) Socket::TcpConnect (host/port = 10.10.2.3) >>>>>>>> TCPSocket::Connect (host/port = 10.10.2.3) Socket::TcpConnect >>>>>>>> (host/port = 10.10.2.3) TCPSocket::Connect (host/port = 10.10.2.3) >>>>>>>> Socket::TcpConnect (host/port = 10.10.2.3) .................. >>>>>>>> .................. >>>>>>>> .................. >>>>>>>> TCPSocket::Connect (host/port = 10.10.2.3) Socket::TcpConnect >>>>>>>> (host/port = 10.10.2.3) TCPSocket::Connect (host/port = 10.10.2.3) >>>>>>>> Socket::TcpConnect (host/port = 10.10.2.3) TCPSocket::Connect >>>>>>>> (host/port = 10.10.2.3) Socket::TcpConnect (host/port = 10.10.2.3) >>>>>>>> TCPSocket::Connect (host/port = 10.10.2.3) Socket::TcpConnect >>>>>>>> (host/port = 10.10.2.3) TCPSocket::Connect (host/port = 10.10.2.3) >>>>>>>> Socket::TcpConnect (host/port = 10.10.2.3) TCPSocket::Connect >>>>>>>> (host/port = 10.10.2.3) >>>>>>>> error: connect remote failed (invalid host:port specification: >>>>>>>> '10.10.2.3') >>>>>>>> 0x915bd78 Communication::Write (src = 0x92b38c4, src_len = 27) >>>>>>>> connection = 0x915f578 >>>>>>>> 0x915f608 Socket::Write() (socket = 7, src = 0x92b38c4, src_len = >>>>>>>> 27, flags = 0) => 27 (error = (null)) < 27> send packet: >>>>>>>> $qKillSpawnedProcess:298#8b this = 0x0915BD78, dst = 0xBFCB509C, >>>>>>>> dst_len = 8192, timeout = 1000000 us, connection = 0x0915F578 >>>>>>>> 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb509c, src_len = >>>>>>>> 7, flags = 0) => 7 (error = (null)) >>>>>>>> < 7> read packet: $E0a#d6 >>>>>>>> error: process launch failed: invalid host:port specification: >>>>>>>> '10.10.2.3' >>>>>>>> (lldb) >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Ramana >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>>> _______________________________________________ >>>>>> 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 _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
