From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4957 invoked by alias); 6 Oct 2008 21:12:51 -0000 Received: (qmail 4949 invoked by uid 22791); 6 Oct 2008 21:12:50 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.113.40.141) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 06 Oct 2008 21:12:08 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 5246D6A2B; Mon, 6 Oct 2008 14:12:07 -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 38BF78E5CA; Mon, 6 Oct 2008 14:12:07 -0700 (PDT) Message-ID: <48EA7EBA.5000106@vmware.com> Date: Mon, 06 Oct 2008 21:12:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Pedro Alves CC: "gdb-patches@sourceware.org" , Daniel Jacobowitz , teawater Subject: Re: [RFA] Reverse Debugging, 2/5 References: <48E3CCE2.3000001@vmware.com> <200810062049.55637.pedro@codesourcery.com> In-Reply-To: <200810062049.55637.pedro@codesourcery.com> Content-Type: text/plain; charset=UTF-8; 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/msg00163.txt.bz2 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... > On Wednesday 01 October 2008 20:17:54, Michael Snyder wrote: >> - status->kind = TARGET_WAITKIND_STOPPED; >> - status->value.sig = TARGET_SIGNAL_0; >> + if (buf[1] == '0' && buf[2] == '6') >> + { >> + status->kind = TARGET_WAITKIND_NO_HISTORY; >> + } >> + else >> + { >> + status->kind = TARGET_WAITKIND_STOPPED; >> + status->value.sig = TARGET_SIGNAL_0; >> + } > > This isn't really an error, it's a defined reply, so it > looks a bit strange to me to be using an error number. > > Is there a reason this can't be reported with a T stop reply and > a special "register", like "library" -> TARGET_WAITKIND_LOADED is? > > AFAICT, nothing else in the remote implementation relies > on defined error numbers currently --- annoying at times, but > doesn't seem to apply here. 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... We could add a new T packet tag, and then threaten to deprecate support for the error reply at some future time. > + > +static enum exec_direction_kind remote_get_execdir (void) > > Function name on the first column please. > > +{ > + if (remote_debug && info_verbose) > + printf_filtered ("remote execdir is %s\n", > + remote_execdir == EXEC_FORWARD ? "forward" : > + remote_execdir == EXEC_REVERSE ? "reverse" : > + "unknown"); > + return remote_execdir; > +} > > This should be made i18n aware. > > Similarly in remote_set_execdir. You got it. ;-) > No new vCont packets -> no plans on reverse + multi-threading ? :-) Noooo... it means no story *now* about reverse and multi-threading. Can always be added in later...