From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10008 invoked by alias); 19 Aug 2009 19:52:33 -0000 Received: (qmail 9998 invoked by uid 22791); 19 Aug 2009 19:52:32 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from oden.vtab.com (HELO oden.vtab.com) (62.20.90.195) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 19 Aug 2009 19:52:23 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id B305526EEF9; Wed, 19 Aug 2009 21:52:19 +0200 (CEST) Received: from polhem (c83-253-21-2.bredband.comhem.se [83.253.21.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oden.vtab.com (Postfix) with ESMTP id 7C29E26EED5; Wed, 19 Aug 2009 21:52:19 +0200 (CEST) From: "Jakob Engblom" To: "'Hui Zhu'" Cc: 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> In-Reply-To: Subject: RE: Simics & reverse execution Date: Wed, 19 Aug 2009 20:03:00 -0000 Message-ID: <010601ca2106$90d41920$b27c4b60$@com> MIME-Version: 1.0 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/msg00180.txt.bz2 > This is really a big mail. And looks like a AD. :) >=20 > I think you mean is simics can support reverse with remote like vmware, r= ight? I think the answer is that method used seems mostly the same.=20=20 The key thing for me was to explain that the time scope of the reversible r= un is potentially larger than what any particular gdb-remote connection sees: i.e= ., it is nice if gdb would accept backing into "before it was attached" logically= , and not assume too much control over the reversing in itself.=20 And that a probe for reversibility in gbd-remote would be a worthwhile addi= tion to the protocol.=20 /jakob =20 > Hui >=20 > On Wed, Aug 19, 2009 at 15:33, Jakob Engblom wrote: > > > > In a thread about testing gdb reverse, Michael Snyder asked this questi= on 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 whic= h is > > fairly similar if more nimble than the VMWare implementation currently). > > > > Essentially, reverse execution is implemented on the hardware level. Si= mics > > simulates an entire system: core processors, their surrounding devices = on a > > typical system-on-chip, memories, disks, networks, PCI, RapidIO, etc. = =A0In > > 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 c= an > record > > any asynchronous user input to a system like network packets and users typing > on > > keyboards attached to virtual systems. =A0To 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. =A0There is a good illustration o= f 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 -- exce= pt that > > there is no recording. But you have a limited window in both cases to w= hich you > > can go back (you start reverse execution at some point in time, which c= ould be > > system boot, or some later point). > > > > When we mix in gdb reverse with this, it is just an interface to the Si= mics > 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 = 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 connecti= on 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 d= ebug. > =A0We > > can also use OS awarenesss to have a remote gdb only debug a certain pr= ocess > > when it is running. =A0 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. =A0In many ways, this= makes > > implementing reverse execution easier: there is a single interface leve= l 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 fu= ture > > where asynchronous input from the user and environment is allowed, and = the > > system will take a different path than it took previously. =A0This does= not > > necessarily need to be addressed over gdb-remote. =A0But it might map t= o 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 c= lock > > around in time arbitrarily. =A0In 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 > >