From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24372 invoked by alias); 28 Dec 2008 11:09:18 -0000 Received: (qmail 24364 invoked by uid 22791); 28 Dec 2008 11:09:17 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 28 Dec 2008 11:08:42 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 7F1F02A95FB; Sun, 28 Dec 2008 06:08:40 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 04RQ8-yYXPY5; Sun, 28 Dec 2008 06:08:40 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id AA88B2A96C0; Sun, 28 Dec 2008 06:08:39 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id DA9CBE7ACD; Sun, 28 Dec 2008 15:08:31 +0400 (RET) Date: Sun, 28 Dec 2008 11:09:00 -0000 From: Joel Brobecker To: Sandra Loosemore Cc: gdb-patches@sourceware.org Subject: Re: RFA: auto-retry TCP connections for "target remote" Message-ID: <20081228110831.GB4216@adacore.com> References: <49553C3A.2070000@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49553C3A.2070000@codesourcery.com> User-Agent: Mutt/1.4.2.2i 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 X-SW-Source: 2008-12/txt/msg00418.txt.bz2 > 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