From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5661 invoked by alias); 19 Aug 2009 08:58:26 -0000 Received: (qmail 5652 invoked by uid 22791); 19 Aug 2009 08:58:25 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from wf-out-1314.google.com (HELO wf-out-1314.google.com) (209.85.200.171) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 19 Aug 2009 08:58:18 +0000 Received: by wf-out-1314.google.com with SMTP id 23so1307774wfg.24 for ; Wed, 19 Aug 2009 01:58:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.4.16 with SMTP id 16mr1253777wfd.88.1250672296060; Wed, 19 Aug 2009 01:58:16 -0700 (PDT) In-Reply-To: <027701ca209f$64c71ce0$2e5556a0$@com> 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> <027701ca209f$64c71ce0$2e5556a0$@com> From: Hui Zhu Date: Wed, 19 Aug 2009 12:29:00 -0000 Message-ID: Subject: Re: Simics & reverse execution To: Jakob Engblom Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00172.txt.bz2 This is really a big mail. And looks like a AD. :) I think you mean is simics can support reverse with remote like vmware, rig= ht? Hui On Wed, Aug 19, 2009 at 15:33, Jakob Engblom wrote: > > 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? =A0If 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. Simi= cs > simulates an entire system: core processors, their surrounding devices on= a > typical system-on-chip, memories, disks, networks, PCI, RapidIO, etc. =A0= In > extreme cases, we are talking about entire virtual networks and virtual S= MP > servers with 10s, 100s, or 1000s of processors. > > The key level that Simics observes is the software interface to the hardw= are. > Simics does not need to know anything about the software to run it, it ju= st > simulates the hardware. > > To reverse execution in Simics, you use a combination of record and reexe= cution > 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 ty= ping on > keyboards attached to virtual systems. =A0To reverse the execution, you j= ump back > to a checkpoint fo the system state and then you reexecute forward, to a = place > before your current position in time. =A0There 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 whi= ch you > can go back (you start reverse execution at some point in time, which cou= ld be > system boot, or some later point). > > When we mix in gdb reverse with this, it is just an interface to the Simi= cs core > engine. =A0Gdb 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 fr= om 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, conne= cting > 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 proce= ssor at > the hardware level, which is useful for bare-hardware or kernel-level deb= ug. =A0We > can also use OS awarenesss to have a remote gdb only debug a certain proc= ess > when it is running. =A0 Note that the Simics reverse affects the entire s= oftware > stack, including any writes to memory, disk, network packets sent, and ke= rnel > process schedulings and interrupts from hardware. =A0In many ways, this m= akes > 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 ti= me > 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 futu= re > where asynchronous input from the user and environment is allowed, and the > system will take a different path than it took previously. =A0This does n= ot > necessarily need to be addressed over gdb-remote. =A0But 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 clo= ck > around in time arbitrarily. =A0In the Simics reverse interface, you can g= o 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 t= hat > talks gdb remote. > > /jakob >