I had a chance to look into this more, and I found a bug in the listen behavior. I'm testing a solution to it now. Will post it if it resolves the issue.
-Chris > On Aug 25, 2017, at 10:36 AM, Greg Clayton via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > 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 _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
