From patchwork Fri Dec 5 12:37:43 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Machado X-Patchwork-Id: 4080 Received: (qmail 11345 invoked by alias); 5 Dec 2014 12:38:00 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 11326 invoked by uid 89); 5 Dec 2014 12:37:59 -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:37:58 +0000 Received: from svr-orw-fem-03.mgc.mentorg.com ([147.34.97.39]) by relay1.mentorg.com with esmtp id 1Xws8x-00048K-4Y from Luis_Gustavo@mentor.com ; Fri, 05 Dec 2014 04:37:55 -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:37:54 -0800 Message-ID: <5481A717.30509@codesourcery.com> Date: Fri, 5 Dec 2014 10:37:43 -0200 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> In-Reply-To: <5481A6C8.6040403@codesourcery.com> X-IsSubscribed: yes 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! 2014-12-05 Luis Machado gdb/testsuite * gdb.cp/typeid.exp (do_typeid_tests): Do not test type id printing unless the symbols are available. diff --git a/gdb/testsuite/gdb.cp/typeid.exp b/gdb/testsuite/gdb.cp/typeid.exp index 9963a8a..54552d4 100644 --- a/gdb/testsuite/gdb.cp/typeid.exp +++ b/gdb/testsuite/gdb.cp/typeid.exp @@ -25,20 +25,34 @@ if {[prepare_for_testing $testfile.exp $testfile $srcfile {debug c++}]} { proc do_typeid_tests {started} { global hex + global gdb_prompt + set symbol_found 1 + + # 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. + gdb_test_multiple "print 'typeinfo for int'" "" { + -re "No symbol \"typeinfo for int\" in current context.*$gdb_prompt $" { + set symbol_found 0 + } + -re ".*$gdb_prompt $" { + } + } # We might see the standard type or gdb's internal type. set type_re "(std::type_info|struct gdb_gnu_v3_type_info)" + if {$symbol_found == 1} { + foreach simple_var {i cp ccp ca b} { + gdb_test "print &typeid($simple_var)" \ + " = \\($type_re \\*\\) $hex.*" - foreach simple_var {i cp ccp ca b} { - gdb_test "print &typeid($simple_var)" \ - " = \\($type_re \\*\\) $hex.*" - - # Note that we test pointer equality rather than object - # equality here. That is because std::type_info's operator== - # is not present in the libstdc++ .so. - gdb_test "print &typeid($simple_var) == &typeid(typeof($simple_var))" \ - " = true" + # Note that we test pointer equality rather than object + # equality here. That is because std::type_info's operator== + # is not present in the libstdc++ .so. + gdb_test "print &typeid($simple_var) == &typeid(typeof($simple_var))" \ + " = true" + } } # typeid for these is Derived. Don't try these tests until the