From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29144 invoked by alias); 19 Aug 2009 07:34:00 -0000 Received: (qmail 29122 invoked by uid 22791); 19 Aug 2009 07:33:55 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from vtab.com (HELO oden.vtab.com) (62.20.90.195) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 19 Aug 2009 07:33:50 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id 41C3A26EF07 for ; Wed, 19 Aug 2009 09:33:47 +0200 (CEST) Received: from polhem (unknown [62.20.90.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oden.vtab.com (Postfix) with ESMTP id 1DB5826EE6A for ; Wed, 19 Aug 2009 09:33:47 +0200 (CEST) From: "Jakob Engblom" To: References: <002001ca1f0e$4c9b74a0$e5d25de0$@com> <002101ca1f2e$746e1ad0$5d4a5070$@com> <200908171251.07179.pedro@codesourcery.com> <4A899E2E.6080203@vmware.com> <00b801ca1f74$e5610a90$b0231fb0$@com> <4A89B7E4.9010804@vmware.com> In-Reply-To: <4A89B7E4.9010804@vmware.com> Subject: Simics & reverse execution Date: Wed, 19 Aug 2009 08:58:00 -0000 Message-ID: <027701ca209f$64c71ce0$2e5556a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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: 2009-08/txt/msg00171.txt.bz2 In a thread about testing gdb reverse, Michael Snyder asked this question about reverse debug and Simics: > I think with your setup, you can make the recording first, > before you ever start gdb, am I right? > > I don't know whether you also have an option to start making > the recording after you start debugging? If so, you might want > to test it in the same context? I think it helps to explain how Simics does reverse execution (and which is fairly similar if more nimble than the VMWare implementation currently). Essentially, reverse execution is implemented on the hardware level. Simics simulates an entire system: core processors, their surrounding devices on a typical system-on-chip, memories, disks, networks, PCI, RapidIO, etc. In extreme cases, we are talking about entire virtual networks and virtual SMP servers with 10s, 100s, or 1000s of processors. The key level that Simics observes is the software interface to the hardware. Simics does not need to know anything about the software to run it, it just simulates the hardware. To reverse execution in Simics, you use a combination of record and reexecution techniques. Simics itself is 100% repeatable in its execution, and it can record any asynchronous user input to a system like network packets and users typing on keyboards attached to virtual systems. To reverse the execution, you jump back to a checkpoint fo the system state and then you reexecute forward, to a place before your current position in time. There is a good illustration of this in the white paper at http://www.virtutech.com/whitepapers/simics_checkpointing.html . Doing reverse breakpoints basically involves successively jumping back and executing forward until breakpoints trigger. I think process record does something very similar, based on the recording, right? >From the outside, the semantics are identical to process record -- except that there is no recording. But you have a limited window in both cases to which you can go back (you start reverse execution at some point in time, which could be system boot, or some later point). When we mix in gdb reverse with this, it is just an interface to the Simics core engine. Gdb reverse can be attached at any point during a run. Often, the way you do things is to boot a machine to prompt (or open the booted state from a checkpoint stored on disk), load target software in some way, and turn on reverse execution when things get interesting: such as setting up the configuration for the software to run, starting dependent services, connecting to network servers, etc. Once the program you want to debug runs, you open a gdb remote connection and attach gdb. Note that Simics by default lets gdb remote control one processor at the hardware level, which is useful for bare-hardware or kernel-level debug. We can also use OS awarenesss to have a remote gdb only debug a certain process when it is running. Note that the Simics reverse affects the entire software stack, including any writes to memory, disk, network packets sent, and kernel process schedulings and interrupts from hardware. In many ways, this makes implementing reverse execution easier: there is a single interface level to attack, no need to udnerstand the operating system on the target. As far as gdb remote is concerned, you can conceptually reverse into a time prior to when gdb remote was attached. The underlying "recording" has no relation to the actions of gdb remote. In simics, there are additional controls than regular debugging, such as turning off reverse execution during a simulation. And "clearing the recording", essentially making the current point in time the start of an unknown future where asynchronous input from the user and environment is allowed, and the system will take a different path than it took previously. This does not necessarily need to be addressed over gdb-remote. But it might map to some of the process record commands quite naturally. What this means for Simics and gdb remote is that it would be nice to be able to deal with points in time: in Simics, you are moving the target system clock around in time arbitrarily. In the Simics reverse interface, you can go to a certain point in time, and also set execution bookmarks. But from a gdb perspective, all of this is hidden in a remote black box that talks gdb remote. /jakob