From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31996 invoked by alias); 6 Oct 2008 21:38:34 -0000 Received: (qmail 31988 invoked by uid 22791); 6 Oct 2008 21:38:34 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 06 Oct 2008 21:37:59 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 348C74000A; Mon, 6 Oct 2008 14:37:56 -0700 (PDT) Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) by mailhost2.vmware.com (Postfix) with ESMTP id 272ED8E5CA; Mon, 6 Oct 2008 14:37:56 -0700 (PDT) Message-ID: <48EA84C6.9080803@vmware.com> Date: Mon, 06 Oct 2008 21:38:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Michael Snyder , Pedro Alves , "gdb-patches@sourceware.org" , teawater Subject: Re: [RFA] Reverse Debugging, 2/5 References: <48E3CCE2.3000001@vmware.com> <200810062049.55637.pedro@codesourcery.com> <48EA7EBA.5000106@vmware.com> <20081006212405.GA31085@caradoc.them.org> In-Reply-To: <20081006212405.GA31085@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/msg00175.txt.bz2 Daniel Jacobowitz wrote: > 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 :-) I see. So we would just make them type "set reverse-supported on" or something like that. > 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. Well, MI isn't in there yet, though I've heard from a possible contributor. How about if we put qSupported into a later patch as well? Nothing wrong with the present target implementers being supported in the first version... >> 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. You're probably right. But it was certainly in my earlier patch submissions.