The patch works for x86 remote debugging as well. $ ../binaries/x86_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
On Tue, Aug 29, 2017 at 10:51 PM, Ramana <ramana.venka...@gmail.com> wrote: > 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
