From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1085 invoked by alias); 27 May 2010 22:50:50 -0000 Received: (qmail 1071 invoked by uid 22791); 27 May 2010 22:50:49 -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 22:50:45 +0000 Received: (qmail 5662 invoked from network); 27 May 2010 22:50:43 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 27 May 2010 22:50:43 -0000 From: Pedro Alves To: Michael Snyder Subject: Re: [RFA] gdb.trace/*.exp send_gdb vs. gdb_test Date: Thu, 27 May 2010 23:15:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-21-generic; KDE/4.3.2; x86_64; ; ) Cc: "gdb-patches@sourceware.org" , Stan Shebs References: <4BFEB77D.4080107@vmware.com> <201005271922.03831.pedro@codesourcery.com> <4BFEC338.6090307@vmware.com> In-Reply-To: <4BFEC338.6090307@vmware.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201005272350.40581.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/msg00670.txt.bz2 On Thursday 27 May 2010 20:08:40, Michael Snyder wrote: > Pedro Alves wrote: > > On Thursday 27 May 2010 19:18:37, Michael Snyder wrote: > >> This patch should get extra-thorough review and preferably be tested by > >> the tracepoint maintainers, since I wasn't able to test all of it. > > > > Did you test it against gdbserver x86 or x86_64? That should cover it: > > > > > > OK thanks. They all work except for limits.exp, which does not run > because it tests "tstatus" before it executes "target remote". Thanks for testing. Indeed, I had never noticed that. I can't say I'm fond of the: "We generously give ourselves one "pass" if we successfully detect that this test cannot be run on this target!" pattern in this tests. :-) I wonder who shall I complain about that to. ;-) 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. I took a look at your patch. > -send_gdb "list $baseline, +12\n" > -gdb_expect { > +gdb_test_multiple "list $baseline, +12" "all tests in this module will fail" { > -re "\[\r\n\](\[0-9\]+).*gdbtestline 1 " { > set testline1 $expect_out(1,string) > exp_continue > @@ -108,7 +107,7 @@ all tests in this module will fail." > untested backtrace.exp > return -1 > all tests in this module will fail." > - } > + } > } > Can you do the return outside of gdb_test_multiple please? I saw a few other instances in tfind.exp. Otherwise, looked fine. -- Pedro Alves