From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20022 invoked by alias); 19 Aug 2009 12:29:10 -0000 Received: (qmail 20003 invoked by uid 22791); 19 Aug 2009 12:29:09 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 19 Aug 2009 12:29:00 +0000 Received: (qmail 5221 invoked from network); 19 Aug 2009 12:28:58 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 19 Aug 2009 12:28:58 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: gdb reverse execution: how to actually run tests for it? Date: Wed, 19 Aug 2009 15:28:00 -0000 User-Agent: KMail/1.9.10 Cc: "Jakob Engblom" , Michael Snyder References: <002001ca1f0e$4c9b74a0$e5d25de0$@com> <200908171251.07179.pedro@codesourcery.com> <024f01ca209e$02d81e40$08885ac0$@com> In-Reply-To: <024f01ca209e$02d81e40$08885ac0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908191328.57310.pedro@codesourcery.com> 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/msg00173.txt.bz2 On Wednesday 19 August 2009 08:23:54, Jakob Engblom wrote: > > # Create an empty file named site.exp. > > # Create a directory named boards in the same location as site.exp. > > # Create a file named native-gdbserver.exp in the boards directory (see > below). > > # Set the DEJAGNU environment variable to point to the empty site.exp. > > # Run the testsuite with make check-gdb RUNTESTFLAGS="--target_board native- > > gdbserver". > > Should such files be part of the gdb source tree, so that the tests for reverse > can be run without having to set up a local special board? For the generic reverse execution tests --- reverse step, reverse next, reverse continue, run to breakpoint in reverse, etc., etc., I'd must prefer that we would get rid of the need for board files at all. :-) 1. for native targets, the only reverse solution we currently support is precord. I can't see why we can't default to testing the reverse tests with precord then. We could still leave the possibility of a dejagnu board variable changing this defaulting, but I don't think we need it currently. Of course, this would be filtered on selected targets. Something along these lines in testsuite/lib/gdb.exp: proc run_reverse_tests_with_precord {} { # Board requested it explicitly. Might want to try # precord against gdbserver. if [target_info exists gdb,use_precord] { return 1 } if { [isnative] && ([istarget "i?86-*-linux*"] || [istarget "x86_64-*-linux*"]) } then { # Nothing else supports precord, yet. return 1 } # Nope, don't use precord. Maybe the target supports reverse # debugging in some other way (e.g., a remote full system emulator) return 0 } Then have the tests check run_reverse_tests_with_precord instead of checking "target_info exists gdb,use_precord". 2. for remove targets, it would be much much better if the remote target reported support for reverse upfront, but, that was never added to the protocol ... Failing that, I still think that a simple probing test would work (try a simple reverse step, and if that fails either claiming the target doesn't support the command, or, it moved forward instead of backwards, then skip all other reverse tests). This way, everyone runs the reverse tests when they do a simple "make check", and we get much better test coverage. As is, only a couple people are running them, as you have to request them explicitly. -- Pedro Alves