From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32372 invoked by alias); 8 Oct 2008 01:46:18 -0000 Received: (qmail 32359 invoked by uid 22791); 8 Oct 2008 01:46:17 -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; Wed, 08 Oct 2008 01:45:34 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 2CD246A13; Tue, 7 Oct 2008 18:45:33 -0700 (PDT) Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) by mailhost3.vmware.com (Postfix) with ESMTP id 1ED6CC9A38; Tue, 7 Oct 2008 18:45:33 -0700 (PDT) Message-ID: <48EC1043.1040706@vmware.com> Date: Wed, 08 Oct 2008 01:46: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: <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> <48EBFEE7.6020500@vmware.com> <20081008005424.GC3810@adacore.com> In-Reply-To: <20081008005424.GC3810@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/msg00233.txt.bz2 Joel Brobecker wrote: >> 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 think that the overloading of the word target is making it very > hard to understand each other. Well, *something* is, that's for sure. Might just be early senility on my part... ;-) > Again, target_set_exec_dir would tell the inferior that, from now on, > the exec direction for all future resumes will be (forward|reverse). But... Oh, I get it. You're right. It is the overloading of "target". Joel, the inferior (in the sense of eg. gdbserver) doesn't have any memory of the exec direction. It's stateless. Each message (eg. 'c' or 'bc') is unaffected by the previous one. So if we remove the memory of the exec state from the target_ops layer and transfer it to the infrun layer, then target_set_execdir will have no semantics at all except "does this work". > If the target method is unset, then we know the feature is unsupported. > If it is set, and it fails, then refuse the change of direction - > feature not supported either. Otherwise, update the infrun direction > with the new direction. > > -- > Joel