From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40097 invoked by alias); 3 Sep 2018 18:49:08 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 39936 invoked by uid 89); 3 Sep 2018 18:48:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 spammy=listening, Hx-languages-length:3327, reside X-HELO: jocasta.intra Received: from de.cellform.com (HELO jocasta.intra) (88.217.224.109) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 03 Sep 2018 18:48:25 +0000 Received: from jocasta.intra (localhost [127.0.0.1]) by jocasta.intra (8.15.2/8.15.2/Debian-8) with ESMTPS id w83Im6LE011203 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 3 Sep 2018 20:48:06 +0200 Received: (from john@localhost) by jocasta.intra (8.15.2/8.15.2/Submit) id w83Im6uZ011202; Mon, 3 Sep 2018 20:48:06 +0200 Date: Mon, 03 Sep 2018 18:49:00 -0000 From: John Darrington To: Pedro Alves Cc: John Darrington , gdb-patches@sourceware.org Subject: Re: [PATCH] Allow remote debugging over a local domain socket Message-ID: <20180903184806.2snsj6eghjdwcnjh@jocasta.intra> References: <874lfd5gjt.fsf@tromey.com> <20180831101818.9175-1-john@darrington.wattle.id.au> <61e78be6-4976-6a28-90d2-e515c0afc2f3@redhat.com> <20180831164001.jcejryh3v7fqtsd3@jocasta.intra> <39de0b1a-eba6-2325-f76e-9dfb54ebd88d@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <39de0b1a-eba6-2325-f76e-9dfb54ebd88d@redhat.com> User-Agent: NeoMutt/20170113 (1.7.2) X-SW-Source: 2018-09/txt/msg00024.txt.bz2 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'