From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65864 invoked by alias); 1 Oct 2018 19:45:58 -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 65837 invoked by uid 89); 1 Oct 2018 19:45:57 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=advantages, reside, Socket, processes X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 01 Oct 2018 19:45:55 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7F43281256; Mon, 1 Oct 2018 19:45:54 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id B87FE627D8; Mon, 1 Oct 2018 19:45:53 +0000 (UTC) Subject: Re: [PATCH] Allow remote debugging over a local domain socket To: John Darrington 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> <20180903184806.2snsj6eghjdwcnjh@jocasta.intra> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <8f22580d-fbd2-e1a8-f0f1-10d3c650cdf9@redhat.com> Date: Mon, 01 Oct 2018 19:45:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180903184806.2snsj6eghjdwcnjh@jocasta.intra> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-10/txt/msg00027.txt.bz2 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 , for example. I'll take a look at your v3 patch, see if I have extra comments. Thanks, Pedro Alves