From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4880 invoked by alias); 6 Oct 2008 21:46:13 -0000 Received: (qmail 4867 invoked by uid 22791); 6 Oct 2008 21:46:12 -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:45:34 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 03C0568D7; Mon, 6 Oct 2008 14:45:32 -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 0D3D98E5CA; Mon, 6 Oct 2008 14:45:32 -0700 (PDT) Message-ID: <48EA868E.3070404@vmware.com> Date: Mon, 06 Oct 2008 21:46:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Michael Snyder , Joel Brobecker , "gdb-patches@sourceware.org" , Pedro Alves , teawater Subject: Re: [RFA] Reverse Debugging, 1/5 References: <48E3CCB6.4060501@vmware.com> <20081006203021.GA21853@adacore.com> <48EA7C75.7070703@vmware.com> <20081006211131.GA26663@caradoc.them.org> <48EA8065.9070001@vmware.com> <20081006212504.GB31085@caradoc.them.org> In-Reply-To: <20081006212504.GB31085@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/msg00178.txt.bz2 Daniel Jacobowitz wrote: > On Mon, Oct 06, 2008 at 02:17:25PM -0700, Michael Snyder wrote: >> You're going to send "to_set_direction" to the target, >> and then you're going to assume that you know what the >> state is later on, rather than asking the target? What >> if the target gets it wrong? Now you're out of sync. > > Huh? No, part of every resume. It's not part of resume. That was the very first design decision. We didn't modify resume, because it would require modifying every existing target. Instead, we added a set execution direction method, which has to be called before resume (and after, depending). So right now there are two ways this gets invoked: 1) By a one-shot reverse command, reverse-xxx (where xxx is step/stepi/next/nexti/continue/finish/until). In that case, we do: target_set_exec_dir (reverse); step/next/finish/continue/??? target_set_exec_dir (forward); 2) By the user command set exec-direction, in which case we leave it in the user-supplied state until the user changes it again. All resumes get the implied direction that was specified in the last target_set_exec_dir. Resume doesn't have an extra parameter, but if you do reverse-step, for instance, there may be many resumes between the two calls to target_set_exec_dir. >> If we do keep the direction-state in the core, where would >> we put it? In the ecs? In a global variable in infrun? > > In infrun, the same as any other user supplied execution state. > For instance the scheduler-locking setting. I'm ok with that, if that's what we decide. But understand -- the target HAS to remember this state, so now we are duplicating state. Unles we go back and reverse that very first design decision and add a parameter to resume -- which will be a lot of work.