From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20827 invoked by alias); 25 Nov 2008 23:09:50 -0000 Received: (qmail 20688 invoked by uid 22791); 25 Nov 2008 23:09:49 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 25 Nov 2008 23:09:14 +0000 Received: (qmail 31798 invoked from network); 25 Nov 2008 23:09:04 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 25 Nov 2008 23:09:04 -0000 From: Pedro Alves To: teawater Subject: Re: [RFA] Resubmit process record and replay, 6/10 Date: Wed, 26 Nov 2008 17:25:00 -0000 User-Agent: KMail/1.9.10 Cc: "Michael Snyder" , "gdb-patches@sourceware.org" References: <200811200214.37330.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200811252309.08704.pedro@codesourcery.com> 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-11/txt/msg00706.txt.bz2 On Monday 24 November 2008 03:23:06, teawater wrote: > > Not sure if it's "are we recording" or are we "replaying", or > > a mix of both. In any case, could each call site on the common > > code be replaced by a new suitable target method/property? > > Could you give me more message on it? I am not very clear your mean. What is the property or state that you want to check here? You should export that through the target_ops interface, instead of making infrun.c tied to a record.c and the record target. Currently, GDB only distinguises reverse and forward execution. Does it also need to know that replaying is a special case of forward execution? Perhaps you want to check if the current target is replaying? target_is_replaying() ? Note that this would be a proper target_ops method, not a reference record_ops, like in your current macro. But, why do you need to protect `proceed' with the record target, while reverse/replay debugging against sid or WMware or Virtutech didn't need it? If they also need it, or will need it, what's the check that GDB should do to prevent the bad writes from happening in those targets too? And, why only in `proceed'? Figuring this out, and knowing *exactly* what is it that this check is protecting against will let us know if there's some other better way. Plain ignoring writes may or may not be the right thing to do here. Can you show an example of what you're protecting against? E.g., should you instead prohibit the 'jump ADDR' command at a higher layer when replaying or executing backwards? -- Pedro Alves