From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4384 invoked by alias); 6 Oct 2008 21:45:38 -0000 Received: (qmail 4374 invoked by uid 22791); 6 Oct 2008 21:45:36 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 06 Oct 2008 21:45:00 +0000 Received: (qmail 5378 invoked from network); 6 Oct 2008 21:44:59 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 6 Oct 2008 21:44:59 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFA] Reverse Debugging, 1/5 Date: Mon, 06 Oct 2008 21:45:00 -0000 User-Agent: KMail/1.9.9 Cc: Michael Snyder , Joel Brobecker , Daniel Jacobowitz , teawater References: <48E3CCB6.4060501@vmware.com> <20081006203021.GA21853@adacore.com> <48EA7C75.7070703@vmware.com> In-Reply-To: <48EA7C75.7070703@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200810062245.31761.pedro@codesourcery.com> 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/msg00177.txt.bz2 On Monday 06 October 2008 22:00:37, Michael Snyder wrote: Certainly you've been through this much more than all of us, so, I'm just going to give a knee-jerk like reaction to this. It's not really a profoundly thought about opinion, so wear sunglasses... > Making no assumptions about HOW the target sets the direction, > it seems likely that at least *some* targets will have to > remember this state locally. Whereas there is no reason > for core-gdb to have to remember the state locally, if it can > always get it from the target. If we consider the packets you're introducing to the remote protocol, it looks a bit that these abstractions colide. That is, if you have a way to set the direction on the target, then you wouldn't need a special step-backwards packet. You'd just pass down the direction and issue a normal step... A per-target property may seems to make sense on single-threaded,single-inferior targets, but when you add support for multi-inferiors per target (e.g., extended-remote has some of it now, and I'm going to push more of it), or multi-threaded support, the per-target setting may not make sense anymore --- explicit requests at the target resume interface (just like your new packets) may make more sense. Imagine forward execution non-stop debugging in all threads but one, which the user is examining in reverse. What's the target direction in this case? > It seems a worse duplication to keep the same state information > simultaneously in the target and in the core, since now you > have to worry about them getting out of sync. > > At worst, a target will need to maintain an int's worth of state > locally, and so long as we're never running two targets at the > same time, there's no synchronization issue. > The question to me is --- when/why does the target (as in, the debug API abstraction) ever need to know about the current direction that it couldn't get from the core's request? -- Pedro Alves