From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11814 invoked by alias); 8 Jun 2018 22:01:29 -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 11313 invoked by uid 89); 8 Jun 2018 22:00:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-7.6 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 08 Jun 2018 22:00:53 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A8149BB42F; Fri, 8 Jun 2018 22:00:51 +0000 (UTC) Received: from localhost (unused-10-15-17-196.yyz.redhat.com [10.15.17.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id C72E17D4FD; Fri, 8 Jun 2018 22:00:48 +0000 (UTC) From: Sergio Durigan Junior To: Pedro Alves Cc: GDB Patches , Eli Zaretskii , Jan Kratochvil , Paul Fertser , Tsutomu Seki Subject: Re: [PATCH] Implement IPv6 support for GDB/gdbserver References: <20180523185719.22832-1-sergiodj@redhat.com> <307a63d3-703d-5611-1508-c80daa86fbbf@redhat.com> <874lieulko.fsf@redhat.com> <8721b020-3b0e-bd66-85dc-5e28aef456a8@redhat.com> <87vaattbjq.fsf@redhat.com> <745457f7-9c87-5e0e-e8df-a58900302da5@redhat.com> <87d0x1t1n8.fsf@redhat.com> <6aa5c695-9ade-dc4f-5f22-b9586b77fb07@redhat.com> Date: Fri, 08 Jun 2018 22:01:00 -0000 In-Reply-To: <6aa5c695-9ade-dc4f-5f22-b9586b77fb07@redhat.com> (Pedro Alves's message of "Fri, 8 Jun 2018 22:51:21 +0100") Message-ID: <877en9szu7.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00238.txt.bz2 On Friday, June 08 2018, Pedro Alves wrote: > On 06/08/2018 10:21 PM, Sergio Durigan Junior wrote: >> On Friday, June 08 2018, Pedro Alves wrote: > >>>> We can either adjust it to a lower delay, get rid of >>>> it, or leave it as is and assume that unprefixed addresses are IPv4. I >>>> fail to see what else we're missing. >>> >>> The "assume unprefixed addresses are IPv4" seems like the worse >>> option to me, as it's a work around. Let's tackle the real issue >>> instead. >>> >>> We could consider for example more verbose progress indication, >>> or cycling the whole "getaddrinfo loop" before waiting to retry instead >>> of waiting after each individual connection failure. >> >> A more verbose indication would be nice, as well as a way to control how >> many retries GDB should perform. >> >> I'm not sure about cycling the whole loop before waiting to retry... I >> mean, it works, but I'm not sure it's what the user would expect from a >> "retry" mechanism. I would expect GDB to "retry this address X times, >> and then go to the next", instead of "retry all the addresses in a >> loop". But that can be documented, sure. > > Cycling the whole loop seems to me the best option. The retry mechanism > exists because: > > @item set tcp auto-retry on > @cindex auto-retry, for remote TCP target > Enable auto-retry for remote TCP connections. This is useful if the remote > debugging agent is launched in parallel with @value{GDBN}; there is a race > condition because the agent may not become ready to accept the connection > before @value{GDBN} attempts to connect. When auto-retry is > enabled, if the initial attempt to connect fails, @value{GDBN} reattempts > to establish the connection using the timeout specified by > @code{set tcp connect-timeout}. > > If we cycle the whole loop before retrying we end up with a tiny tiny race > window where gdb may have tried IPv6, that failing because gdbserver was not > listening yet, and then gdb trying IPv4 and that succeeding. In that rare > scenario, if gdb had started looping just a fraction of a second earlier, it > would have connected with IPv6 successfully. But, so what? It will have connected > successfully anyway, and IPv6 vs IPv4 will hardly make a real difference. > Users that really really really want to ensure to get IPv6 or IPv4 should use > the "tcp6:" or "tcp4:" prefixes. So I'm not seeing any downside the whole loop > approach. OK, I don't really mind enough to argue. I'll implement it this way. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/