Remote debugging ARM target from x86 host

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_build:332e31302e33312d6c7473692d30323836312d6738303161343066;os_kernel:233520534d5020467269204d61792031332031353a35383a3232204953542032303136;hostname: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:2f686f6d652f72616d616e616e2f776f726b5f726f6f742f546f545f6c6c64622f74657374732f6d61696e;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

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?

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

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.

I suggest turning on more logging - specifically, "gdb-remote process". That's the channel used in StartDebugServerProcess.

Greg, Ted

Thanks for your comments.

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

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.

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.

Ted

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, 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

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

Maybe we can make it open only an IPv4 socket for lldb-server for now as a work around?

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

Very nice! Look forward to seeing what you find.

Thank you, Chris. Looking forward to the patch.

I committed a fix in r312008. Please test it to verify that it resolves your issue.

Thanks,
-Chris

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

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