Maybe we can make it open only an IPv4 socket for lldb-server for now as a work around?
> On Aug 25, 2017, at 8:47 AM, Chris Bieneman <cbiene...@apple.com> wrote: > > 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
