From: Sergio Durigan Junior <sergiodj@redhat.com>
To: Pedro Alves <palves@redhat.com>
Cc: GDB Patches <gdb-patches@sourceware.org>,
Eli Zaretskii <eliz@gnu.org>,
Jan Kratochvil <jan.kratochvil@redhat.com>,
Paul Fertser <fercerpav@gmail.com>,
Tsutomu Seki <sekiriki@gmail.com>
Subject: Re: [PATCH] Implement IPv6 support for GDB/gdbserver
Date: Fri, 08 Jun 2018 22:01:00 -0000 [thread overview]
Message-ID: <877en9szu7.fsf@redhat.com> (raw)
In-Reply-To: <6aa5c695-9ade-dc4f-5f22-b9586b77fb07@redhat.com> (Pedro Alves's message of "Fri, 8 Jun 2018 22:51:21 +0100")
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/
next prev parent reply other threads:[~2018-06-08 22:01 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-23 21:48 Sergio Durigan Junior
2018-05-23 23:40 ` Eli Zaretskii
2018-05-24 0:41 ` Sergio Durigan Junior
2018-05-24 16:54 ` Eli Zaretskii
2018-05-25 1:57 ` Sergio Durigan Junior
2018-05-31 20:10 ` Sergio Durigan Junior
2018-06-06 12:26 ` Pedro Alves
2018-06-08 1:13 ` Sergio Durigan Junior
2018-06-08 13:53 ` Pedro Alves
2018-06-08 17:47 ` Sergio Durigan Junior
2018-06-08 18:44 ` Pedro Alves
2018-06-08 19:28 ` Pedro Alves
2018-06-08 19:51 ` Pedro Alves
2018-06-08 20:43 ` Sergio Durigan Junior
2018-06-08 21:21 ` Sergio Durigan Junior
2018-06-08 21:51 ` Pedro Alves
2018-06-08 22:01 ` Sergio Durigan Junior [this message]
2018-06-15 0:25 ` [PATCH v2] " Sergio Durigan Junior
2018-06-15 7:12 ` Eli Zaretskii
2018-06-20 15:24 ` Pedro Alves
2018-06-21 4:54 ` Sergio Durigan Junior
2018-07-07 20:47 ` [PATCH v3] " Sergio Durigan Junior
2018-07-11 12:55 ` Pedro Alves
2018-07-11 19:13 ` Sergio Durigan Junior
2018-07-11 19:16 ` [PATCH v4] " Sergio Durigan Junior
2018-07-11 21:48 ` Pedro Alves
2018-07-11 23:43 ` Sergio Durigan Junior
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=877en9szu7.fsf@redhat.com \
--to=sergiodj@redhat.com \
--cc=eliz@gnu.org \
--cc=fercerpav@gmail.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=palves@redhat.com \
--cc=sekiriki@gmail.com \
/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).