From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2126 invoked by alias); 7 Oct 2008 00:45:54 -0000 Received: (qmail 2116 invoked by uid 22791); 7 Oct 2008 00:45:54 -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; Tue, 07 Oct 2008 00:45:19 +0000 Received: from mailhost4.vmware.com (mailhost4.vmware.com [10.16.67.124]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id E3F5B67AD; Mon, 6 Oct 2008 17:45:15 -0700 (PDT) Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) by mailhost4.vmware.com (Postfix) with ESMTP id 1F0CDC9A23; Mon, 6 Oct 2008 17:45:16 -0700 (PDT) Message-ID: <48EAB0AD.30906@vmware.com> Date: Tue, 07 Oct 2008 00:45:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Joel Brobecker CC: "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> <48EA868E.3070404@vmware.com> <20081006222258.GF21853@adacore.com> In-Reply-To: <20081006222258.GF21853@adacore.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/msg00191.txt.bz2 Joel Brobecker wrote: >>> 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. > > I don't think that adding a parameter to resume will be beneficial > at this point. But I think it would be beneficial to have it in > infrun instead of having the extra target method - the "target" > in GDB's sense of the target layer doesn't have to remember the > direction, since it can query infrun. All right, I know when I'm licked. ;-) Before I actually implement this, let me see if we're all on the same page (Daniel, Joel, Pedro...) If I put the "exec_direction" state variable in infrun, then there's no point in having EITHER target vector (target_set_execdir or target_get_execdir). It'll just be an ordinary gdb "set" command. But then I ought to add a new target vector, something like "to_can_go_backward" (ok, to_can_reverse), because I've presently overloaded this functionality onto the target_get/set_execdir methods. Then, on "set exec-dir reverse", infrun will call target_can_reverse, and reject accordingly. The target_ops, such as remote.c, instead of checking its own local state variable, will call infrun_get_exec_direction every time target_resume is called. Right?