Re: RFA: auto-retry TCP connections for "target remote"

[Joel Brobecker <brobecker@adacore.com>]

> When cross-debugging on a target that uses a debugging stub or external 
> simulator that speaks GDB remote protocol, we'd like to have Eclipse 
> automatically launch the stub, as well as GDB, when the user clicks on the 
> "Debug" button.  Unfortunately, there's a race condition here: GDB may try 
> to open the TCP port to the stub before the stub has finished its own 
> initialization and started listening for a connection, which leaves GDB 
> with a "connection refused" error and the stub stuck waiting for a 
> connection that never arrives.

It's really funny that we just started looking at the same issue as
well, as we're extending our own gdb-testsuite infrastructure to
support gdbserver testing.

In our case, we looked at the problem differently, and decided that
the gdb-testsuite would try a few times, rather than retrying at
the TCP level. I agree that a retry mechanism in GDB itself would
be very useful, as every front-end out there would otherwise have
to implement their own retry mechanism. So I really support the idea.

I'm just wondering why you chose to implement the idea inside ser-tcp?
Especially since the name of the associated settings "remote auto-retry"
and "remote connect-timeout" does not suggest that it is specific to
a particular transport protocol.

I wonder if it wouldn't be both simpler and more general to do everything
at the remote.c level.Something like replacing the call to serial_open ()
by a loop that calls serial_open a few times until we either succeed or
exceed the number of retries. What do others think? 

> +set remote auto-retry (on|off)
> +show remote auto-retry

Rather than having an on-off setting, can we have a setting that
allows us to configure the maximum number of retries. If set to zero,
then it's equivalent to "auto-retry off".



-- 
Joel