From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19216 invoked by alias); 17 Aug 2009 19:57:22 -0000 Received: (qmail 19207 invoked by uid 22791); 17 Aug 2009 19:57:21 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from dns.vtab.com (HELO oden.vtab.com) (62.20.90.195) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 17 Aug 2009 19:57:09 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id 3D55026EF64 for ; Mon, 17 Aug 2009 21:57:06 +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 DAA2A26EF1C for ; Mon, 17 Aug 2009 21:57:05 +0200 (CEST) From: "Jakob Engblom" To: References: <002001ca1f0e$4c9b74a0$e5d25de0$@com> <002101ca1f2e$746e1ad0$5d4a5070$@com> <200908171251.07179.pedro@codesourcery.com> <4A899E2E.6080203@vmware.com> In-Reply-To: <4A899E2E.6080203@vmware.com> Subject: RE: gdb reverse execution: how to actually run tests for it? Date: Mon, 17 Aug 2009 20:08:00 -0000 Message-ID: <00b801ca1f74$e5610a90$b0231fb0$@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/msg00154.txt.bz2 > Hello Jakob -- welcome back! >=20 > Pedro's reply below includes answers to most of your questions. > This is some background. >=20 > 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.=20 However, we are not really developing a new platform here. We are just doin= g MI comamnds for reverse that should work on any reversible platform. Therefor= e, it would be nice to generalize reverse to be independent of the particular implementation.=20 But I get the sense here that process record is a bit too special or convol= uted to serve as a general reversible platform. It seems that the recording proc= ess is shining through, in some way. Is that right? =20 > 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: >=20 > 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.=20 > So you will want to have this in your board description file: >=20 > set_board_info gdb,can_reverse 1 >=20 > Secondly, there are a few commands that are specific to > "process record", so I guarded them with this variable: >=20=20 > 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.=20 Best regards, /jakob _______________________________________________________ Jakob Engblom, PhD, Technical Marketing Manager Virtutech=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Direct: +46= 8 690 07 47=A0=A0=A0 Drottningholmsv=E4gen 22=A0=A0=A0=A0=A0 Mobile: +46 709 242 646=A0=A0 11243 Stockholm=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Web:=A0=A0=A0 www.virtu= tech.com=A0 Sweden ________________________________________________________ =A0=20