Re: [PATCH] Allow remote debugging over a local domain socket

[John Darrington <john at darrington dot wattle dot id dot au>]

Hi Pedro,

On Mon, Sep 03, 2018 at 02:18:55PM +0100, Pedro Alves wrote:

     > Yes.  One of the big advantages of using local sockets in testing as
     > opposed to tcp sockets is that parallel tests become a lot easier.  
     
     That's not what I suggested.  The server-connect.exp test does this:
     
      # Test multiple types of connection (IPv4, IPv6, TCP, UDP) and make
      # sure both gdbserver and GDB work.
     
     so what I meant was that we could add unix socket testing to that file
     in order to smoke test unix socket work and continue working, regardless
     of how the rest of the testsuite is being run.

Oh right.  Yes that could be done, but like you said it would involve 
modifying gdbserver.

     Can you clarify how unix sockets are different from tcp sockets here?

1.  Unix sockets have a (almost) infinite choice of connection points.
Whereas TCP sockets you're limited by the port number (usually 16 bits).

2.  One can never be sure that a TCP port doesn't already have something
listening on it.  So starting a server cannot be guaranteed to succeed.
Whereas with a Unix socket you can create the directory where the file
entry is to reside and know it'll be empty.

3.  If a server listening on a TCP socket crashes, then that port number
will be unavailable until the kernel's timeout expires (usually after ~
2 minutes).  You cannot restart the server until that happens.   There
is no way (outside of unloading the kernel's TCP/IP stack) to force the
port to become a available again.  With Unix sockets, you simply unlink
the filename.

4.  Unix sockets can only be used for communication between processes on
the same host.
     
     
     > 
     > I'm not sure if that's entirely safe.  I believe some systems define
     > sun_path as a pointer into a static buffer in the kernel.  
     
     How can userspace have a pointer into kernel memory?

I recall from Stevens or somewhere that some systems used to 
define struct socket_un like 
{
  int sun_family;
  char *sun_path;
}

or something.   I don't remember the details of which system it was or
how it worked.
     
     
         OpenBSD: 104 characters
         FreeBSD: 104 characters
         Mac OS X 10.9: 104 characters
     
     So hardcoding to 108 seems worse to me.

I thought posix required a minimum of 108.
     
     Regardless, seems odd to have different parts of gdb use different
     fallbacks.  Ideally, we'd move the fallback definition to a single
     place used by both users. 

I don't mind. If you want me to copy the macro from there, I can do
that.
     
     All these files provide different implementations of serial transports
     (as opposed to parallel), abstracted behind "struct serial", and to
     be used with the "remote SERIAL protocol".  It's not that tangential.
     
     We have three host-specific files named such that their name indicates
     the host which they are for:
     
      "ser-unix.c", "ser-go32.c" and "ser-mingw.c".
     
     Then we have host-independent files that are named wrt to the
     transport they implement internally:
     
      "ser-event.c", "ser-pipe.c", "ser-tcp.c".
     
     ser-event.c is a bit of an outlier, if you'd like to
     pick on some case.
     
     > It could use a big rename action ...
     
     Sure, it could be better.  
     
     But, is "socket" your ideal choice?

My first choice was ser-unix.c but that is already taken.   I really
don't have a preference.  What would you prefer?  ser-local.c perhaps?

     
Thanks for the review.

J'