From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12536 invoked by alias); 15 Dec 2014 12:29:07 -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 12523 invoked by uid 89); 15 Dec 2014 12:29:06 -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; Mon, 15 Dec 2014 12:29:05 +0000 Received: from svr-orw-fem-02x.mgc.mentorg.com ([147.34.96.206] helo=SVR-ORW-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1Y0Ulp-000396-Ti from Luis_Gustavo@mentor.com ; Mon, 15 Dec 2014 04:29:01 -0800 Received: from [172.30.6.22] (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.3.181.6; Mon, 15 Dec 2014 04:29:01 -0800 Message-ID: <548ED403.2060306@codesourcery.com> Date: Mon, 15 Dec 2014 12:29: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> <5481A6C8.6040403@codesourcery.com> <5481A717.30509@codesourcery.com> In-Reply-To: <5481A717.30509@codesourcery.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00376.txt.bz2 Ping! On 12/05/2014 10:37 AM, Luis Machado wrote: > On 12/05/2014 10:36 AM, Luis Machado wrote: >> 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? >> >> > > Of course, now actually attaching the patch itself! > >