From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26586 invoked by alias); 27 May 2010 23:15:53 -0000 Received: (qmail 26578 invoked by uid 22791); 27 May 2010 23:15:53 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 27 May 2010 23:15:46 +0000 Received: (qmail 19978 invoked from network); 27 May 2010 23:15:44 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 27 May 2010 23:15:44 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFA] gdb.trace/*.exp send_gdb vs. gdb_test Date: Thu, 27 May 2010 23:25:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-21-generic; KDE/4.3.2; x86_64; ; ) Cc: Michael Snyder , Stan Shebs References: <4BFEB77D.4080107@vmware.com> <4BFEC338.6090307@vmware.com> <201005272350.40581.pedro@codesourcery.com> In-Reply-To: <201005272350.40581.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201005280015.41580.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-05/txt/msg00671.txt.bz2 On Thursday 27 May 2010 23:50:40, Pedro Alves wrote: > Let me try to fix that before you commit. Should be simple. > Other tests had the same issue, and I thought I had fixed them > all, but obviously this one slipped. Oh bummer. The patch pasted at the end fixes that, but... gdb.sum: Running target native-gdbserver Running ../../../src/gdb/testsuite/gdb.trace/limits.exp ... FAIL: gdb.trace/limits.exp: maint packet QTLimit:tp:ffffffff PASS: gdb.trace/limits.exp: This test cannot be run on this target === gdb Summary === # of expected passes 1 # of unexpected failures 1 gdb.log: (gdb) maint packet QTLimit:tp:ffffffff sending: "QTLimit:tp:ffffffff" received: "" (gdb) FAIL: gdb.trace/limits.exp: maint packet QTLimit:tp:ffffffff ... the test is using an undocumented packet to set artificial limits on the remote tracing engine. GDBserver doesn't implement that packet. I had never heard of this packet, and I'm not sure it makes much sense to have this test nowadays. Can we just get rid of the whole test file? Otherwise, the "doesn't support this packet" detection looks bogus: if [gdb_test "maint packet QTLimit:tp:ffffffff" \ "received: .OK." ""] then { pass "This test cannot be run on this target" return 1; } The test is skipped if the target returns something that contains "OK" ?? --- gdb/testsuite/gdb.trace/limits.exp | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) Index: src/gdb/testsuite/gdb.trace/limits.exp =================================================================== --- src.orig/gdb/testsuite/gdb.trace/limits.exp 2010-05-28 00:08:29.000000000 +0100 +++ src/gdb/testsuite/gdb.trace/limits.exp 2010-05-28 00:08:18.000000000 +0100 @@ -22,6 +22,7 @@ if $tracelevel then { set testfile "limits" set srcfile ${testfile}.c +set executable $testfile set binfile $objdir/$subdir/$testfile if { [gdb_compile "$srcdir/$subdir/$srcfile" $binfile \ @@ -294,11 +295,9 @@ proc gdb_trace_limits_tests { } { # Start with a fresh gdb. -gdb_exit -gdb_start -gdb_reinitialize_dir $srcdir/$subdir -gdb_load $binfile - +clean_restart $executable +runto_main + if [target_info exists gdb_stub] { gdb_step_for_stub; }