From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2774 invoked by alias); 6 Oct 2008 21:03:07 -0000 Received: (qmail 2699 invoked by uid 22791); 6 Oct 2008 21:03:06 -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; Mon, 06 Oct 2008 21:02:28 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id C22A013007; Mon, 6 Oct 2008 14:02:26 -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 B70B38E5CA; Mon, 6 Oct 2008 14:02:26 -0700 (PDT) Message-ID: <48EA7C75.7070703@vmware.com> Date: Mon, 06 Oct 2008 21:03: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" , Daniel Jacobowitz , Pedro Alves , teawater Subject: Re: [RFA] Reverse Debugging, 1/5 References: <48E3CCB6.4060501@vmware.com> <20081006203021.GA21853@adacore.com> In-Reply-To: <20081006203021.GA21853@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/msg00161.txt.bz2 Joel Brobecker wrote: >> 2008-09-30 Michael Snyder >> Target interface for reverse debugging. >> * target.h (enum target_waitkind): >> Add new wait event, TARGET_WAITKIND_NO_HISTORY. >> (enum exec_direction_kind): New enum. >> (struct target_ops): New methods to_set_execdir, to_get_execdir. >> * target.c (target_get_execdir): New generic method. >> (target_set_execdir): Ditto. > > One of the questions I'm asking myself is why having the get_execdir > method? It seems that, once we have called "target_sets_execdir" and > it hasn't returned ERROR, core GDB should know what the execution > direction is, no? Is there a situation where a round-trip to the > target would be necessary? Otherwise, we'll end up with the target > code all doing the same thing, which is caching the current value > of the same thing. > > One thing that crossed my mind while thinking about it is whether > we want to make this property global to all inferiors or specific > to each inferior. Ahem, shall we say global? It was a design choice. There were two choices: 1) modify target_resume (ops->to_resume), to add a direction parameter. 2) Add a to_set_direction target method. The first would have required modifying all existing targets, so I chose the second. Once you have a "set" method, it seems logical to have a "get" method. Making no assumptions about HOW the target sets the direction, it seems likely that at least *some* targets will have to remember this state locally. Whereas there is no reason for core-gdb to have to remember the state locally, if it can always get it from the target. It seems a worse duplication to keep the same state information simultaneously in the target and in the core, since now you have to worry about them getting out of sync. At worst, a target will need to maintain an int's worth of state locally, and so long as we're never running two targets at the same time, there's no synchronization issue.