From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24299 invoked by alias); 15 Oct 2008 18:20:26 -0000 Received: (qmail 24290 invoked by uid 22791); 15 Oct 2008 18:20:26 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 15 Oct 2008 18:19:51 +0000 Received: from mailhost5.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 2F3E35C008 for ; Wed, 15 Oct 2008 11:19:49 -0700 (PDT) Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) by mailhost5.vmware.com (Postfix) with ESMTP id 1FBD7DC053; Wed, 15 Oct 2008 11:19:49 -0700 (PDT) Message-ID: <48F63377.5020307@vmware.com> Date: Wed, 15 Oct 2008 18:20:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Michael Snyder , "gdb-patches@sourceware.org" Subject: Re: [RFA] Resubmit, reverse debugging [0/5] References: <48EC1781.2030005@vmware.com> <48EF93A5.7060808@vmware.com> <20081010175332.GA9028@caradoc.them.org> <48EFA065.5070108@vmware.com> <20081010185808.GA12193@caradoc.them.org> <48EFCFEE.3090007@vmware.com> <20081014122648.GB7471@caradoc.them.org> In-Reply-To: <20081014122648.GB7471@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00374.txt.bz2 Daniel Jacobowitz wrote: > On Fri, Oct 10, 2008 at 02:58:06PM -0700, Michael Snyder wrote: >> OK, here's a patch that adds >> 1) remote protocol documentation >> 2) The requested extension to the 'T' reply to replace E06 >> 3) A big honking "deprecated" warning for E06. > > I'm even fine with the warning being replaced by a comment. The most > important part, IMO, is having a non-hackish version of the protocol > implemented and documented. All right, so that's in. We also discussed earlier the idea of a capability check, or like a qSupported message. Are we going to make that a requirement before this patch can go in? Or can it be added as a subsequent, incremental improvement? And are there any more requirements before this patch can go in?