From patchwork Tue Aug 23 16:17:10 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carl Love X-Patchwork-Id: 14881 Received: (qmail 25277 invoked by alias); 23 Aug 2016 16:17:18 -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 25265 invoked by uid 89); 23 Aug 2016 16:17:17 -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, RCVD_IN_DNSWL_LOW, RCVD_IN_SEMBACKSCATTER, SPF_PASS autolearn=ham version=3.3.2 spammy=Frame X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 23 Aug 2016 16:17:16 +0000 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u7NGE0Rh034751 for ; Tue, 23 Aug 2016 12:17:15 -0400 Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by mx0a-001b2d01.pphosted.com with ESMTP id 250pg75fj8-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 23 Aug 2016 12:17:15 -0400 Received: from localhost by e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 23 Aug 2016 10:17:14 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e38.co.us.ibm.com (192.168.1.138) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 23 Aug 2016 10:17:12 -0600 X-IBM-Helo: d03dlp02.boulder.ibm.com X-IBM-MailFrom: cel@us.ibm.com Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id AF6D93E40062; Tue, 23 Aug 2016 10:17:11 -0600 (MDT) Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u7NGHBgp57344174; Tue, 23 Aug 2016 09:17:11 -0700 Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1F0017803F; Tue, 23 Aug 2016 10:17:11 -0600 (MDT) Received: from [9.70.82.29] (unknown [9.70.82.29]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP id BC5B878041; Tue, 23 Aug 2016 10:17:10 -0600 (MDT) Subject: Re: [PATCH] Fix for gdb.base/pc-fp.exp. From: "Carl E. Love" To: Pedro Alves Cc: Ulrich Weigand , Edjunior Barbosa Machado , gdb-patches@sourceware.org Date: Tue, 23 Aug 2016 09:17:10 -0700 In-Reply-To: <8f1a63df-5140-831e-0892-34be046144c5@redhat.com> References: <1471900578.4102.36.camel@us.ibm.com> <8f1a63df-5140-831e-0892-34be046144c5@redhat.com> Mime-Version: 1.0 X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16082316-0028-0000-0000-0000056ECC91 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00005634; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000183; SDB=6.00748613; UDB=6.00353333; IPR=6.00521278; BA=6.00004672; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00012436; XFM=3.00000011; UTC=2016-08-23 16:17:13 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16082316-0029-0000-0000-00002E9B6F03 Message-Id: <1471969030.4102.52.camel@us.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-23_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608230161 On Tue, 2016-08-23 at 00:17 +0100, Pedro Alves wrote: > Can you provide more details? > > E.g.: > > What's was wrong? What failed? Why is removing this line the > right fix? > > I'm not suggesting that the fix is wrong (or right, I have no > idea). Just pointing out that context is missing. > > Thanks, > Pedro Alves > Here is an updated patch with the missing detail. -------------------------------------------------------------------------- Fix for gdb.base/pc-fp.exp. It is my understanding that GDB used to require each architecture to define a Frame Pointer (fp). However, this functionality was deprecated some time ago so the call to setup the fp_reg was changed to deprecated (set_gdbarch_deprecated_fp_regnum). It should have been removed from the Power code. That said, the code "set_gdbarch_deprecated_fp_regnum (gdbarch, PPC_R0_REGNUM + 1);" sets up register r1 as the frame pointer. Register r1 is no longer used to hold the frame pointer on Power. By removing the fp definition for Power in GDB, it causes GDB to fall back to the call get_frame_base_address (frame) which returns the correct value depending on the specific senario but most of the time is the DWARF canonical frame address. gdb/ChangeLog 2016-08-22 Carl Love * rs6000-tdep.c (rs6000_gdbarch_init): Remove deprecated call set_gdbarch_deprecated_fp_regnum() from Power architecture initialization function. --- gdb/rs6000-tdep.c | 1 - 1 file changed, 1 deletion(-) diff --git a/gdb/rs6000-tdep.c b/gdb/rs6000-tdep.c index a616cbe..db63be0 100644 --- a/gdb/rs6000-tdep.c +++ b/gdb/rs6000-tdep.c @@ -5957,7 +5957,6 @@ rs6000_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches) set_gdbarch_pc_regnum (gdbarch, PPC_PC_REGNUM); set_gdbarch_sp_regnum (gdbarch, PPC_R0_REGNUM + 1); - set_gdbarch_deprecated_fp_regnum (gdbarch, PPC_R0_REGNUM + 1); set_gdbarch_fp0_regnum (gdbarch, tdep->ppc_fp0_regnum); set_gdbarch_register_sim_regno (gdbarch, rs6000_register_sim_regno);