From: Pedro Alves <palves@redhat.com>
To: John Darrington <john@darrington.wattle.id.au>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Allow remote debugging over a local domain socket
Date: Mon, 01 Oct 2018 19:45:00 -0000 [thread overview]
Message-ID: <8f22580d-fbd2-e1a8-f0f1-10d3c650cdf9@redhat.com> (raw)
In-Reply-To: <20180903184806.2snsj6eghjdwcnjh@jocasta.intra>
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
next prev parent reply other threads:[~2018-10-01 19:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-29 7:05 Remote debugging over local domain sockets? John Darrington
2018-08-29 15:17 ` Tom Tromey
2018-08-29 15:28 ` John Darrington
2018-08-29 15:39 ` Tom Tromey
2018-08-31 10:18 ` [PATCH] Allow remote debugging over a local domain socket John Darrington
2018-08-31 14:59 ` Eli Zaretskii
2018-08-31 15:10 ` John Darrington
2018-08-31 17:50 ` Eli Zaretskii
2018-08-31 15:10 ` Tom Tromey
2018-08-31 15:12 ` John Darrington
2018-08-31 16:01 ` Pedro Alves
2018-08-31 16:40 ` John Darrington
2018-09-03 13:19 ` Pedro Alves
2018-09-03 18:49 ` John Darrington
2018-10-01 19:45 ` Pedro Alves [this message]
2018-10-02 10:16 ` John Darrington
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8f22580d-fbd2-e1a8-f0f1-10d3c650cdf9@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=john@darrington.wattle.id.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).