From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29884 invoked by alias); 2 Jun 2010 19:42:58 -0000 Received: (qmail 29866 invoked by uid 22791); 2 Jun 2010 19:42:56 -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 smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 02 Jun 2010 19:42:52 +0000 Received: from jupiter.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id D6FF14B07F; Wed, 2 Jun 2010 12:42:48 -0700 (PDT) Received: from msnyder-server.eng.vmware.com (promd-2s-dhcp138.eng.vmware.com [10.20.124.138]) by jupiter.vmware.com (Postfix) with ESMTP id CF82BDC2A5; Wed, 2 Jun 2010 12:42:48 -0700 (PDT) Message-ID: <4C06B438.1090508@vmware.com> Date: Wed, 02 Jun 2010 19:42:00 -0000 From: Michael Snyder User-Agent: Thunderbird 2.0.0.22 (X11/20090609) MIME-Version: 1.0 To: Pedro Alves CC: "gdb-patches@sourceware.org" , Stan Shebs Subject: Re: [RFA] gdb.trace/*.exp send_gdb vs. gdb_test References: <4BFEB77D.4080107@vmware.com> <201005271922.03831.pedro@codesourcery.com> <4BFEC338.6090307@vmware.com> <201005272350.40581.pedro@codesourcery.com> In-Reply-To: <201005272350.40581.pedro@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit 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-06/txt/msg00050.txt.bz2 Pedro Alves wrote: > 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. Done and committed. By the way, would you take a look at the diff just above? What is "all tests in this module will fail" doing there? The same thing appears in both backtrace.exp and report.exp.