Re: [PATCH] Implement IPv6 support for GDB/gdbserver

[Pedro Alves <palves@redhat.com>]

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