[PATCH] Implement IPv6 support for GDB/gdbserver

[Sergio Durigan Junior]

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/