[PATCH] D42845: Add an option 'allow-all-hosts' to permit lldb debugging inside a Docker container

[Alex Blewitt via llvm-commits]

> On 7 Feb 2018, at 07:30, Pavel Labath <labath at google.com> wrote:
> 
> On 7 February 2018 at 15:03, Alex Blewitt <alblue at apple.com> wrote:
>> What I do is set up Docker to forward the connections via the specific ports
>> - in effect, the Docker app is listening on localhost:4000, then it routes
>> packets through into inside the Docker instance and changes the IP address.
> Right, and for the llgs connection, I presume you have a similar
> setup, where docker listens on localhost:4001 and forwards to
> (virtual) 172.17.0.2:4001.
> 
> 
>> So getpeername inside the Docker instance is getting a different IP address
>> than the connection that the lldb client thinks it is.
> 
> Now this is the part I don't get. It's true that the client sends it's
> own hostname as a part of the launch request, but that is currently
> being ignored by the platform:
> GDBRemoteCommunicationServerPlatform.cpp:107
>  // ignore the hostname send from the remote end, just use the ip address
>  // that we're currently communicating with as the hostname
> 
> My guess is this is done precisely so that your use case could work.
> And it should work because LLGS will be comparing getpeername() of the
> platform connection with getpeername() of the LLGS one, and these
> should match as both are taken from the inside of the docker image.
> Why it doesn't work is something I'd like to figure out, as I think
> your use case should work out-of-the-box.
> 
> Can you repeat your netstat experiment with both of the connections
> (LLGS and platform) active, so we can see how all addresses are
> resolved?

Here's what it looks like inside the container - the 4000 is the platform server and the 4001 is the child gdbserver process:

# netstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 f6c9d51504e8:4000       172.17.0.1:55212        ESTABLISHED
tcp        0      0 f6c9d51504e8:4001       172.17.0.1:58322        ESTABLISHED
tcp        0      0 f6c9d51504e8:4000       172.17.0.1:55216        ESTABLISHED

(in this case, I've restarted the docker image so there's a different name)

# cat /etc/hosts
127.0.0.1	localhost
172.17.0.2	f6c9d51504e8

This is what the connection looks like from outside the container, looking in:

$ netstat -n | grep 400
tcp4       0      0  127.0.0.1.4001         127.0.0.1.53809        ESTABLISHED
tcp4       0      0  127.0.0.1.53809        127.0.0.1.4001         ESTABLISHED
tcp4       0      0  127.0.0.1.4000         127.0.0.1.53808        ESTABLISHED
tcp4       0      0  127.0.0.1.53808        127.0.0.1.4000         ESTABLISHED
tcp4       0      0  127.0.0.1.4000         127.0.0.1.53806        ESTABLISHED
tcp4       0      0  127.0.0.1.53806        127.0.0.1.4000         ESTABLISHED

These are the processes running in the Docker container, with the 0.0.0.0 signifying the patch working:

   66 pts/0    Sl+    0:00 lldb-server platform --allow-all-hosts --server --listen *:4000 --min-gdbserver-port 4001 --max-gdbserver-port 
   70 pts/0    S+     0:00 /usr/bin/lldb-server gdbserver tcp://0.0.0.0:4001 --native-regs --log-file=/tmp/lldb-gdbserver.log

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180207/e0eff435/attachment.html>