From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27966 invoked by alias); 23 Oct 2008 03:39:27 -0000 Received: (qmail 27958 invoked by uid 22791); 23 Oct 2008 03:39:27 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.191) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 23 Oct 2008 03:38:52 +0000 Received: by ti-out-0910.google.com with SMTP id d10so51119tib.12 for ; Wed, 22 Oct 2008 20:38:48 -0700 (PDT) Received: by 10.110.11.7 with SMTP id 7mr30092tik.43.1224733128771; Wed, 22 Oct 2008 20:38:48 -0700 (PDT) Received: by 10.110.42.9 with HTTP; Wed, 22 Oct 2008 20:38:48 -0700 (PDT) Message-ID: Date: Thu, 23 Oct 2008 03:39:00 -0000 From: teawater To: "Michael Snyder" Subject: Re: [discuss] semantics, "replay debugging" vs. "reverse debugging" Cc: "Daniel Jacobowitz" , "Jakob Engblom" , "gdb@sourceware.org" In-Reply-To: <48FF6C46.1020402@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48FBDA34.6020104@vmware.com> <007e01c9334e$aad56ff0$00804fd0$@com> <20081022133716.GA10237@caradoc.them.org> <48FF6C46.1020402@vmware.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-10/txt/msg00100.txt.bz2 Sorry buddies. Maybe I spend too much time to think about the implement. :) And even if in same size insn set arch and insn is like "add r0,r0,#10". It can't reverse without record yet. Cause when you want reverse execute, you need load insn. But you don't know where are you form. From prev insn or a long address that have a jump insn. Of course, you can just record the PC, not record other thing. :) On Thu, Oct 23, 2008 at 02:09, Michael Snyder wrote: > teawater wrote: >> >> Sorry I am wrong. >> In ARM, Just adds set cpsr reg. So: >> add r0,r0,#10 >> Can reverse without record too. > > OK, well, I was really speaking in the abstract. > I only meant "it's possible to imagine a target or > architecture in which reverse execution can be done > by some means other than record/replay". > > Didn't necessarily mean that it could be done on any > real, existing architecture. > >