From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124557 invoked by alias); 8 Jun 2018 21:51:32 -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 124543 invoked by uid 89); 8 Jun 2018 21:51:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-7.3 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 21:51:30 +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 F0C0EBB42F; Fri, 8 Jun 2018 21:51:28 +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 1C9F983B72; Fri, 8 Jun 2018 21:51:21 +0000 (UTC) Subject: Re: [PATCH] Implement IPv6 support for GDB/gdbserver To: Sergio Durigan Junior 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> Cc: GDB Patches , Eli Zaretskii , Jan Kratochvil , Paul Fertser , Tsutomu Seki From: Pedro Alves Message-ID: <6aa5c695-9ade-dc4f-5f22-b9586b77fb07@redhat.com> Date: Fri, 08 Jun 2018 21:51:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <87d0x1t1n8.fsf@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-06/txt/msg00237.txt.bz2 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. > > On a side note, I have to ask: why not decrease the number of retries > to, say, 5? This would still add a delay, but it'd be much shorter. Because the solution above sounds much better to me. No delay. > We should add this to a wiki or to our official docs. I think it's the > more complete explanation I've read about gdbreplay so far. That might be a good idea. Thanks, Pedro Alves