From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20598 invoked by alias); 6 Oct 2008 22:14:00 -0000 Received: (qmail 20589 invoked by uid 22791); 6 Oct 2008 22:13:59 -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 22:13:08 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 9F536686D; Mon, 6 Oct 2008 15:13:04 -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 708058E5CE; Mon, 6 Oct 2008 15:13:04 -0700 (PDT) Message-ID: <48EA8D02.4030107@vmware.com> Date: Mon, 06 Oct 2008 22:14: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" , Joel Brobecker , Daniel Jacobowitz , teawater Subject: Re: [RFA] Reverse Debugging, 1/5 References: <48E3CCB6.4060501@vmware.com> <20081006203021.GA21853@adacore.com> <48EA7C75.7070703@vmware.com> <200810062245.31761.pedro@codesourcery.com> In-Reply-To: <200810062245.31761.pedro@codesourcery.com> 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/msg00182.txt.bz2 Pedro Alves wrote: > 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... "With Reverse Debugging, the future's so bright, ya gotta wear shades!" ;-) >> 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... Sorry, verbal ambiguity on my part. Where I've been saying "target" in this thread, I have been meaning "the target_ops implementation", eg. (but not limited to) remote.c I believe you're thinking "target" as in for instance "gdbserver" or VirtuTech/Simics simulator. Two different API's. The API for the target_ops target is target_set_exec_dir target_resume target_wait This has an explicit persistant state -- the exec_dir. The API for remote targets is 'c', 'bc', 's', 'bs'. In this, there is no persistant state. But it's important to remember that GDB proper does not know anything about the remote protocol API. Only one or more target_ops implementations know about that, and there is no particular reason for the two APIs to resemble each other. The API for (eg.) a native target is likely to be completely different. > 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? Yakkk!!! OK, I don't have a story for multi-thread reverse yet, at all, and I certainly don't have one for multi-thread in which some threads are running forward and others are running in reverse! Nor do I have a story for multi-process or multi-target. Planning ahead is great, but at some point, you have to say "that's for a later patch". >> 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? At this interface layer, the core's requests look like: target_set_exec_dir target_resume target_wait [repeat] target_set_exec_dir So there may be many resume/wait calls between calls to set_exec_dir. This means that the target_ops module MUST remember the state, whether or not the core remembers it also.