From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22685 invoked by alias); 8 Oct 2008 00:32:07 -0000 Received: (qmail 22676 invoked by uid 22791); 8 Oct 2008 00:32:07 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 08 Oct 2008 00:31:31 +0000 Received: from mailhost5.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 54F1D3A008; Tue, 7 Oct 2008 17:31:29 -0700 (PDT) Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) by mailhost5.vmware.com (Postfix) with ESMTP id 4A8AFDC0BB; Tue, 7 Oct 2008 17:31:29 -0700 (PDT) Message-ID: <48EBFEE7.6020500@vmware.com> Date: Wed, 08 Oct 2008 00:32: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: <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> <48EAB0AD.30906@vmware.com> <20081007034840.GE28138@adacore.com> <48EBAA24.2080700@vmware.com> <20081008001541.GA3810@adacore.com> In-Reply-To: <20081008001541.GA3810@adacore.com> Content-Type: text/plain; charset=us-ascii; 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/msg00231.txt.bz2 Joel Brobecker wrote: >>> My own view was a little simpler: Delete the target_set_execdir method, >> I'm guessing you meant "get" here? > > Ooops! yes, that' right. > >>> and replace all the calls with a reference to the infrun global. I would >>> keep the target_set_execdir more or less as is; otherwise, you'll need >>> some kind of observer to notice when the execdir changes. The >>> "to_can_go_backwards" is an interesting idea, but in my opinion only >>> makes sense if the target_set_execdir method is removed. Otherwise, >>> we can treat target_set_execdir == NULL as cannot-go-backwards. >> OK, so you're saying that "target_set_execdir" will set the >> global infrun variable, not a target-defined variable? > > Not quite, actually. Roughly, when the user changes the exec direction, > we call target_set_execdir and, if the call succeeded, then update the > direction known in infrun. Or perhaps you or others have better ideas? Just, well, then target_set_execdir does not actually set the exec direction -- instead it sort of tells you if it's *ok* to set the exec direction -- which is what I would think of as target_can_reverse. I'm putting this together, and will have a new patch submission shortly.