From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10891 invoked by alias); 17 Aug 2009 20:08:19 -0000 Received: (qmail 10788 invoked by uid 22791); 17 Aug 2009 20:08:18 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 17 Aug 2009 20:08:08 +0000 Received: from mailhost4.vmware.com (mailhost4.vmware.com [10.16.67.124]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 409772406D; Mon, 17 Aug 2009 13:08:05 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by mailhost4.vmware.com (Postfix) with ESMTP id 38077C9A34; Mon, 17 Aug 2009 13:08:05 -0700 (PDT) Message-ID: <4A89B7E4.9010804@vmware.com> Date: Mon, 17 Aug 2009 22:44:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Jakob Engblom CC: "gdb@sourceware.org" Subject: Re: gdb reverse execution: how to actually run tests for it? References: <002001ca1f0e$4c9b74a0$e5d25de0$@com> <002101ca1f2e$746e1ad0$5d4a5070$@com> <200908171251.07179.pedro@codesourcery.com> <4A899E2E.6080203@vmware.com> <00b801ca1f74$e5610a90$b0231fb0$@com> In-Reply-To: <00b801ca1f74$e5610a90$b0231fb0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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/msg00155.txt.bz2 Jakob Engblom wrote: >> Hello Jakob -- welcome back! >> >> Pedro's reply below includes answers to most of your questions. >> This is some background. >> >> It is normal for those of us doing development on new or >> unusual platforms to need to define a "board description file", >> to let Dejagnu know how to do certain things with our target. >> See "site.exp" in Pedro's email. > > Thanks! Obviously, we had no idea at all of this. > > However, we are not really developing a new platform here. We are just doing MI > comamnds for reverse that should work on any reversible platform. Therefore, it > would be nice to generalize reverse to be independent of the particular > implementation. > > But I get the sense here that process record is a bit too special or convoluted > to serve as a general reversible platform. It seems that the recording process > is shining through, in some way. Is that right? The recording process is visible, yes -- process record is implemented entirely within gdb, so the command to start making a recording is given from within gdb. 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? >> For the reverse debugging tests, I used this guard variable >> to make sure the tests would only run on targets that were >> explicitly tagged as being reverse-capable: >> >> if ![target_info exists gdb,can_reverse] { >> return >> } > > That makes sense. So here we need a board file to say that our native > record/replay is reversible. > >> So you will want to have this in your board description file: >> >> set_board_info gdb,can_reverse 1 >> >> Secondly, there are a few commands that are specific to >> "process record", so I guarded them with this variable: >> >> if [target_info exists gdb,use_precord] { >> # Activate process record/replay >> gdb_test "record" "" "Turn on process record" >> } > > Do any of these need MI equivalents... > >> You won't want to use those commands, so you will >> not define that variable in your board description. > > Will you do MI for them then? :) > >> If there are any commands that are unique to your >> implementation, you can define your own guard variable >> and add them to the tests. > > There should not be. We want Simics to be like any other reversible target, and > the MI command set we are trying to do tests for should as I say be general to > any reversible target. > > > Best regards, > > /jakob > > _______________________________________________________ > > Jakob Engblom, PhD, Technical Marketing Manager > > Virtutech Direct: +46 8 690 07 47 > Drottningholmsvägen 22 Mobile: +46 709 242 646 > 11243 Stockholm Web: www.virtutech.com > Sweden > ________________________________________________________ > > > > >