From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9364 invoked by alias); 5 Dec 2014 12:36:41 -0000 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 Received: (qmail 9351 invoked by uid 89); 5 Dec 2014 12:36:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 05 Dec 2014 12:36:39 +0000 Received: from svr-orw-fem-03.mgc.mentorg.com ([147.34.97.39]) by relay1.mentorg.com with esmtp id 1Xws7f-0003kt-HG from Luis_Gustavo@mentor.com ; Fri, 05 Dec 2014 04:36:35 -0800 Received: from [172.30.1.198] (147.34.91.1) by svr-orw-fem-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server id 14.3.181.6; Fri, 5 Dec 2014 04:36:35 -0800 Message-ID: <5481A6C8.6040403@codesourcery.com> Date: Fri, 05 Dec 2014 12:36:00 -0000 From: Luis Machado Reply-To: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Sergio Durigan Junior CC: "'gdb-patches@sourceware.org'" Subject: Re: [PATCH] Fix gdb.cp/typeid.exp failures for ppc64 References: <547C9087.1090506@codesourcery.com> <878uiryux9.fsf@redhat.com> In-Reply-To: <878uiryux9.fsf@redhat.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00130.txt.bz2 On 12/01/2014 06:30 PM, Sergio Durigan Junior wrote: > On Monday, December 01 2014, Luis Machado wrote: > >> This test assumes the typeid symbols are always available before >> actually starting the inferior, which is not true for architectures >> that place such symbols under relocatable sections. >> >> The following patch fixes this by conditionalizing the execution of >> such tests on the accessibility of the typeid symbols before the >> inferior is running. >> >> Regression-tested on ppc32/64. > > Hey Luis! > > Thanks for the patch. Just a somewhat minor comment. > >> diff --git a/gdb/testsuite/gdb.cp/typeid.exp b/gdb/testsuite/gdb.cp/typeid.exp >> index 9963a8a..7469b2b 100644 >> --- a/gdb/testsuite/gdb.cp/typeid.exp >> +++ b/gdb/testsuite/gdb.cp/typeid.exp >> @@ -25,20 +25,35 @@ if {[prepare_for_testing $testfile.exp $testfile $srcfile {debug c++}]} { >> >> proc do_typeid_tests {started} { >> global hex >> + global gdb_prompt >> + set symbol_found 1 >> >> - # We might see the standard type or gdb's internal type. >> - set type_re "(std::type_info|struct gdb_gnu_v3_type_info)" >> + # Try to access one of the symbols to make sure it is available. Some >> + # architectures put the symbols on relocatable sections, which means >> + # they will not be accessible before the inferior is running. >> + send_gdb "print 'typeinfo for int'\n" >> + gdb_expect { >> + -re "No symbol \"typeinfo for int\" in current context.*$gdb_prompt" { >> + set symbol_found 0 >> + } >> + -re ".*$gdb_prompt" { >> + } >> + } > > Any particular reason for not using gdb_test_multiple here (and > everywhere else)? This "send_gdb...gdb_expect" dialect is not used > anymore in the testsuite, AFAIR. > It looks a bit more natural when you are aiming at tests that should not expose PASS/FAIL. But gdb_test_multiple can be used that way as well, though with a somewhat strange empty testname parameter. Works the same though. I've updated the patch and fixed a previous gotcha in the logic. Ok?