From patchwork Wed Jun 18 08:48:02 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Machado X-Patchwork-Id: 1544 Received: (qmail 28305 invoked by alias); 18 Jun 2014 08:48:14 -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 28268 invoked by uid 89); 18 Jun 2014 08:48:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL, BAYES_00 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; Wed, 18 Jun 2014 08:48:09 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1WxBXK-0000jU-14 from Luis_Gustavo@mentor.com for gdb-patches@sourceware.org; Wed, 18 Jun 2014 01:48:06 -0700 Received: from SVR-ORW-FEM-06.mgc.mentorg.com ([147.34.97.120]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jun 2014 01:48:05 -0700 Received: from [172.30.72.8] (147.34.91.1) by SVR-ORW-FEM-06.mgc.mentorg.com (147.34.97.120) with Microsoft SMTP Server id 14.2.247.3; Wed, 18 Jun 2014 01:48:05 -0700 Message-ID: <53A15242.2070105@codesourcery.com> Date: Wed, 18 Jun 2014 09:48:02 +0100 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: "'gdb-patches@sourceware.org'" Subject: [PATCH, testsuite] Fix gdb.cp/nsalias.exp issues X-IsSubscribed: yes Hi, I've been chasing failures on gdb.cp/nsalias.exp for MIPS, but the strange thing is that the failures only reproduced with a GDB built without optimization. Upon further investigation, i noticed the testcase was generating DW_AT_high_pc and DW_AT_low_pc entries with type DW_FORM_string, which is wrong. GDB was using that information to load data as strings, and then proceeded to use the string pointers as addresses. Even then, the test was passing just fine, because we were lucky enough to have the low_pc string pointer smaller than the high_pc string pointer. The following patch fixes two issues. The first one is the DW_FORM_string type. The second one is adjusting the addresses so that they are non-zero, since GDB doesn't like seeing 0 in these fields due to a check contained in dwarf2_get_pc_bounds: if (low == 0 && !dwarf2_per_objfile->has_section_at_zero) return 0; With both fixes, the testcase passes deterministically, and the failures i saw for the MIPS case were bad luck with the pointer comparisons. OK? 2014-06-18 Luis Machado * gdb.cp/nsalias.exp: Set type of low_pc and high_pc entries to DW_FORM_addr and use non-zero addresses. diff --git a/gdb/testsuite/gdb.cp/nsalias.exp b/gdb/testsuite/gdb.cp/nsalias.exp index f99b609..1179c1c 100644 --- a/gdb/testsuite/gdb.cp/nsalias.exp +++ b/gdb/testsuite/gdb.cp/nsalias.exp @@ -153,20 +153,20 @@ Dwarf::assemble $asm_file { subprogram { {specification :$im_foo_label} - {low_pc 0x0} - {high_pc 0x1} + {low_pc 0x1 DW_FORM_addr } + {high_pc 0x2 DW_FORM_addr } } subprogram { {specification :$i_foo_label} - {low_pc 0x2} - {high_pc 0x3} + {low_pc 0x3 DW_FORM_addr } + {high_pc 0x4 DW_FORM_addr } } subprogram { {specification :$o_foo_label} - {low_pc 0x4} - {high_pc 0x5} + {low_pc 0x5 DW_FORM_addr } + {high_pc 0x6 DW_FORM_addr } } } }