From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32760 invoked by alias); 20 Apr 2006 19:22:45 -0000 Received: (qmail 32752 invoked by uid 22791); 20 Apr 2006 19:22:45 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 20 Apr 2006 19:22:42 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k3KJMewo016886; Thu, 20 Apr 2006 15:22:40 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k3KJMdCW016442; Thu, 20 Apr 2006 15:22:40 -0400 Received: from [172.16.24.50] (bluegiant.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k3KJMbTq016734; Thu, 20 Apr 2006 15:22:38 -0400 Message-ID: <4447DF7D.6070506@redhat.com> Date: Thu, 20 Apr 2006 19:22:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) MIME-Version: 1.0 To: Daniel Jacobowitz CC: Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [RFA] Reverse debugging, part 1/3: target interface References: <442DAA70.5070203@redhat.com> <444426C7.6020604@redhat.com> <20060418125836.GB10130@nevyn.them.org> <20060418152443.GA13825@nevyn.them.org> <44456356.8090706@redhat.com> <444680C3.1010007@redhat.com> <20060420134343.GC11710@nevyn.them.org> In-Reply-To: <20060420134343.GC11710@nevyn.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-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00292.txt.bz2 Daniel Jacobowitz wrote: > On Wed, Apr 19, 2006 at 11:26:11AM -0700, Michael Snyder wrote: > >>+@item bc >>+@cindex @samp{bc} packet >>+Continue execution in reverse (if capable). >>+@xref{Reverse Execution, ,Running programs backward}. >>+ >>+Reply: >>+@xref{Stop Reply Packets}, for the reply specifications. >>+ >>+@item bs >>+@cindex @samp{bs} packet >>+Single step in reverse (if capable). >>+@xref{Reverse Execution, ,Running programs backward}. >>+ >>+Reply: >>+@xref{Stop Reply Packets}, for the reply specifications. >>+ > > > You designed the target interface so that it could return EXEC_ERROR, > "I don't support reverse execution". But here you've got only bc and > bs; you've got no way to probe the remote target for reverse execution > support. Yes, I think I remarked on the need for that in comments. > I realize you've got at least one already shipping stub for this; can > we still fix it, or should we assume that there will be at least one > target where the only way to find out is to try? No problem -- it's not actually shipping, or even promised. This has been a rare, redhat-funded pure research project. ;-) Yes, I appreciate how lucky I am. Thank you, oh employer mine. [not that we don't hope to make money from it eventually...] > This seems to be one of the stray FIXMEs in this code which really > ought to be fixed before we merge it: > > + /* FIXME: check target for capability. */ > > I'm guessing you haven't tried this with a remote target that didn't > support it. It looks like it would fail messily. Hmmmmm... ok, your guess is correct. I propose a deal -- I'll try it, and if it does fail messily, I will fix it. If it doesn't, will you let me check it in with the expectation of future enhancement? I feel that for a major new functionality, useability rather than completeness should be the mark. It's not like we're not going to add to what's been implemented so far. > Are there other hard cases that should be discussed in the remote > protocol documentation, or handled by the protocol? The first one that > comes to mind is "what do we do with threads" - is it ever going to be > relevant to do this in a multi-threaded system, and if so, are we going > to reverse all threads at once? I think in previous discussion, we have recognized that this is a hard problem, and I have simply deferred addressing it. I don't even claim to know if it *can* be addressed. I'd like to say, we can now use this feature on the non-trivial subset of non- threaded programs, and put threaded programs down as a hoped- for future enhancement. > Oh, and refering to Stop Reply Packets is not complete for the reply; > that doesn't cover error codes. For instance, you have one error code > designated to mean "no more history". That should be in the > documentation, please. Well, yes, I thought about that -- but in fact, AFAICT there is *no* documentation for error codes, and I didn't feel like starting it. Yes, I think we need some, but it's probably worth having a discussion of how we would like to do it. And, self-interest not withstanding, I don't think there's a good reason for holding up this patch for lack of something that is lacking throughout. > I've only skimmed the patch; are there others? None that I'm deliberately withholding. ;-) I'm counting on you reviewers to help find any that I've overlooked. Thanks for your review and feedback.