Thanks Chris. The patch woks for ARM remote debugging for my case. I am yet to check x86 remote debugging. Need to build the tool chain, so will update you tomorrow.
~# /mnt/var/arm_debug/bin/lldb --version lldb version 6.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk revision 312008) clang revision 312008 llvm revision 312008 "gdb-remote process" log of lldb-server says GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 55874 port ~/Ramana# ps af -w PID TTY STAT TIME COMMAND 8314 pts/0 S+ 0:00 \_ /mnt/var/arm_debug/bin/lldb-server p --log-file Ramana/remote.log --log-channels gdb-remote process --server --listen *:1400 8421 pts/0 Sl+ 0:01 \_ /mnt/var/arm_debug/bin/lldb-server p --log-file Ramana/remote.log --log-channels gdb-remote process --server --listen *:1400 8477 pts/0 S+ 0:00 \_ /mnt/var/arm_debug/bin/lldb-server gdbserver tcp://10.10.12.3:0 --native-regs --pipe 7 8514 pts/0 t 0:00 \_ /home/root/arm_main ~/work_root/ToT_lldb/tests$ ../binaries/x86_debug/bin/lldb (lldb) platform select remote-linux Platform: remote-linux Connected: no (lldb) platform connect connect://10.10.2.1:1400 Platform: remote-linux Triple: arm-*-linux-gnueabihf OS Version: 4.1.33 (4.1.33-ltsi-altera) Kernel: #1 SMP Tue May 2 08:13:11 MYT 2017 Hostname: arria5 Connected: yes WorkingDir: /home/root (lldb) file arm_main Current executable set to 'arm_main' (arm). (lldb) b main Breakpoint 1: where = arm_main`main + 4 at main.c:4, address = 0x000104a0 (lldb) run Process 8514 launched: '/home/ramanan/work_root/ToT_lldb/tests/arm_main' (arm) Process 8514 stopped * thread #1, name = 'arm_main', stop reason = breakpoint 1.1 frame #0: 0x000104a0 arm_main`main at main.c:4 1 #include <stdio.h> 2 3 int main() { -> 4 printf("Hello World\n"); 5 } (lldb) n Hello World Process 8514 stopped * thread #1, name = 'arm_main', stop reason = step over frame #0: 0x000104ae arm_main`main at main.c:5 2 3 int main() { 4 printf("Hello World\n"); -> 5 } Regards, Ramana On Tue, Aug 29, 2017 at 9:49 PM, Chris Bieneman <cbiene...@apple.com> wrote: > I committed a fix in r312008. Please test it to verify that it resolves your > issue. > > Thanks, > -Chris > >> On Aug 28, 2017, at 8:41 PM, Ramana <ramana.venka...@gmail.com> wrote: >> >> Thank you, Chris. Looking forward to the patch. >> >> On Tue, Aug 29, 2017 at 1:28 AM, Chris Bieneman <cbiene...@apple.com> wrote: >>> 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
