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

[Pedro Alves <palves at redhat dot com>]

On 09/03/2018 07:48 PM, John Darrington wrote:
> 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.

What I meant with "different ... here" was, how are unix domain sockets
different from tcp sockets with respect to:

 "This is because there is a race condition in a server between the 
 bind and listen syscalls.  GDB must not attempt to connect until
 listen has returned successfully."

If GDB attempts to connect to a tcp gdbserver before it listens/binds,
then the connection will fail too.  Except, GDB retries the
connection, but that would be the case with unix domain sockets
too, no?

Re. your point 3 above, I don't observe that with gdbserver, maybe
because it enables fast reuse with SO_REUSEADDR.

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

Please do.

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

As I had mentioned before, if "unix" is taken, I'd prefer "ser-uds.c", for
"Unix Domain Socket", and uds_ as function/symbol prefix.  I think UDS
is quite established and clearer than "local".  I get where it comes
from, but note how "local" isn't even ever mentioned anywhere in
 <https://en.wikipedia.org/wiki/Unix_domain_socket>,
for example.

I'll take a look at your v3 patch, see if I have extra comments.

Thanks,
Pedro Alves