From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11246 invoked by alias); 7 Oct 2008 18:30:26 -0000 Received: (qmail 11238 invoked by uid 22791); 7 Oct 2008 18:30:25 -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 18:29:48 +0000 Received: from mailhost5.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 97F66645F; Tue, 7 Oct 2008 11:29:46 -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 E4A01DC0A6; Tue, 7 Oct 2008 11:29:46 -0700 (PDT) Message-ID: <48EBAA24.2080700@vmware.com> Date: Tue, 07 Oct 2008 18:30: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> <48EAB0AD.30906@vmware.com> <20081007034840.GE28138@adacore.com> In-Reply-To: <20081007034840.GE28138@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/msg00219.txt.bz2 Joel Brobecker wrote: >> Before I actually implement this, let me see if we're all >> on the same page (Daniel, Joel, Pedro...) > > My own view was a little simpler: Delete the target_set_execdir method, I'm guessing you meant "get" here? > 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? I would have thought somebody would object to that on semantic grounds. Then the only reason to put it into the target vector is so that we can check for "cannot-go-backwards", and surely someone will come back and tell me "well that is what you should call it then".