From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20900 invoked by alias); 26 Nov 2008 03:04:22 -0000 Received: (qmail 20884 invoked by uid 22791); 26 Nov 2008 03:04:21 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.184) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 26 Nov 2008 03:03:46 +0000 Received: by ti-out-0910.google.com with SMTP id d10so115098tib.12 for ; Tue, 25 Nov 2008 19:03:43 -0800 (PST) Received: by 10.110.109.12 with SMTP id h12mr7624994tic.56.1227668623724; Tue, 25 Nov 2008 19:03:43 -0800 (PST) Received: by 10.110.103.3 with HTTP; Tue, 25 Nov 2008 19:03:43 -0800 (PST) Message-ID: Date: Wed, 26 Nov 2008 20:44:00 -0000 From: teawater To: "Pedro Alves" Subject: Re: [RFA] Resubmit process record and replay, 6/10 Cc: "Michael Snyder" , "gdb-patches@sourceware.org" In-Reply-To: <200811252309.08704.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811200214.37330.pedro@codesourcery.com> <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/msg00710.txt.bz2 About RECORD_IS_USED, it's mean that record target is used by GDB. #define RECORD_IS_USED \ (current_target.beneath == &record_ops) About "record_not_record_set", I told it with Muhael in another thread. Maybe it will be moved to record_wait in replay mode, record_insert_breakpoint and record_remove_breakpoint. Thanks, Hui On Wed, Nov 26, 2008 at 07:09, Pedro Alves wrote: > 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 >