From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17760 invoked by alias); 6 Oct 2008 21:24:49 -0000 Received: (qmail 17537 invoked by uid 22791); 6 Oct 2008 21:24:48 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 06 Oct 2008 21:24:08 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 931C110D56; Mon, 6 Oct 2008 21:24:06 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 7E83C10D34; Mon, 6 Oct 2008 21:24:06 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KmxYj-0008AU-Sp; Mon, 06 Oct 2008 17:24:05 -0400 Date: Mon, 06 Oct 2008 21:24:00 -0000 From: Daniel Jacobowitz To: Michael Snyder Cc: Pedro Alves , "gdb-patches@sourceware.org" , teawater Subject: Re: [RFA] Reverse Debugging, 2/5 Message-ID: <20081006212405.GA31085@caradoc.them.org> Mail-Followup-To: Michael Snyder , Pedro Alves , "gdb-patches@sourceware.org" , teawater References: <48E3CCE2.3000001@vmware.com> <200810062049.55637.pedro@codesourcery.com> <48EA7EBA.5000106@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48EA7EBA.5000106@vmware.com> User-Agent: Mutt/1.5.17 (2008-05-11) 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/msg00169.txt.bz2 On Mon, Oct 06, 2008 at 02:10:18PM -0700, Michael Snyder wrote: > Pedro Alves wrote: >> On Wednesday 01 October 2008 20:17:54, Michael Snyder wrote: >>> + /* TODO: check target for capability. */ >> >> Can we address this? If you want to be able to query for support, >> it would be a matter of defining a new qSupported feature. > > OK -- but what about existing targets that support reverse, > but don't know about the qSupported query? > > When I put that comment in, I probably intended an implied > question-mark -- that is, I wasn't asserting that a query > would be useful, just wondering aloud... All qSupported probes can be overridden by a manual setting. I don't feel particularly bad about forcing people to update, if there's a workaround - that's part of getting protocol changes merged :-) However, I'm not completely sure it's necessary in this case. When do we check for capability? If it's only at the appropriate run/continue command, then probing is OK - though this would make it hard to, e.g., automatically enable IDE buttons. > Yeah, I hear ya -- I'm not crazy about it either, and I > don't think I knew about the idea of adding new tags onto > the "T" packet two years ago. > > But... the discussion about the remote protocol for this > happened back in '06. There are now targets out in the field > that implement it this way. It would be bad form to break them... I'm pretty sure nothing about this error was in that discussion. At least, I think I would have objected at the time. -- Daniel Jacobowitz CodeSourcery