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

[Pavel Labath via llvm-commits]

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?


> $ docker exec netstat
> Active Internet connections (w/o servers)
> Proto Recv-Q Send-Q Local Address           Foreign Address         State
> tcp        0      0 bc4caa7a55c8:4000       172.17.0.1:55204

What IP does "bc4caa7a55c8" resolve to? Can you try netstat -n ?