From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8014 invoked by alias); 11 Oct 2008 09:47:17 -0000 Received: (qmail 8005 invoked by uid 22791); 11 Oct 2008 09:47:16 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 11 Oct 2008 09:46:41 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id BEA572A9692; Sat, 11 Oct 2008 05:46:39 -0400 (EDT) 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 gikb3NrF8f2V; Sat, 11 Oct 2008 05:46:39 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 72B7F2A9617; Sat, 11 Oct 2008 05:46:39 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id CDD7FE7ACD; Sat, 11 Oct 2008 02:46:36 -0700 (PDT) Date: Sat, 11 Oct 2008 09:47:00 -0000 From: Joel Brobecker To: Michael Snyder Cc: "gdb-patches@sourceware.org" Subject: Re: [RFA] Resubmit, reverse debugging [0/5] Message-ID: <20081011094636.GA3613@adacore.com> References: <48EC1781.2030005@vmware.com> <48EF93A5.7060808@vmware.com> <20081010175332.GA9028@caradoc.them.org> <48EFA065.5070108@vmware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48EFA065.5070108@vmware.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-10/txt/msg00331.txt.bz2 > OK, I agree -- but it's in use, in the field. I don't see this as a factor. If people want to use the version of the protocol that has been deployed, then they can stick with the debugger provided by the associated vendors. If they want to use the FSF GDB, then they have to migrate. We're not suddenly dropping a feature that we used to support. If we look at Ada as an example, there are several features that AdaCore contributed which got redesigned as the result of the review process. That meant that people using GPS (AdaCore's GUI) would have some compatibility issues with the FSF GDB for a while, until we enhanced GDB to recognize the way we implemented the given feature for the FSF. We have done that a few times, now. Personally, after having had protocol compatibility issues between a vendor-supplied gdbserver and our GDB, putting a new packet only to remove it later is, IMO, asking for the same trouble again. -- Joel