From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97668 invoked by alias); 23 Aug 2016 17:06:28 -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 97654 invoked by uid 89); 23 Aug 2016 17:06:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=luis, love X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 23 Aug 2016 17:06:26 +0000 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u7NH4Srd028415 for ; Tue, 23 Aug 2016 13:06:25 -0400 Received: from e06smtp08.uk.ibm.com (e06smtp08.uk.ibm.com [195.75.94.104]) by mx0a-001b2d01.pphosted.com with ESMTP id 24y4q8jdnq-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 23 Aug 2016 13:06:24 -0400 Received: from localhost by e06smtp08.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 23 Aug 2016 18:06:22 +0100 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp08.uk.ibm.com (192.168.101.138) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 23 Aug 2016 18:06:21 +0100 X-IBM-Helo: d06dlp02.portsmouth.uk.ibm.com X-IBM-MailFrom: uweigand@de.ibm.com X-IBM-RcptTo: gdb-patches@sourceware.org Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 85845219004D for ; Tue, 23 Aug 2016 18:05:44 +0100 (BST) Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u7NH6Kd816384424 for ; Tue, 23 Aug 2016 17:06:20 GMT Received: from d06av04.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u7NH6Jj4027596 for ; Tue, 23 Aug 2016 11:06:20 -0600 Received: from oc7340732750.ibm.com (dyn-9-152-213-149.boeblingen.de.ibm.com [9.152.213.149]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u7NH6JvV027589; Tue, 23 Aug 2016 11:06:19 -0600 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id 2D2C75BCB; Tue, 23 Aug 2016 19:06:19 +0200 (CEST) Subject: Re: [PATCH] Fix for gdb.base/pc-fp.exp. To: lgustavo@codesourcery.com Date: Tue, 23 Aug 2016 17:06:00 -0000 From: "Ulrich Weigand" Cc: cel@us.ibm.com (Carl E. Love), palves@redhat.com (Pedro Alves), Ulrich.Weigand@de.ibm.com (Ulrich Weigand), emachado@linux.vnet.ibm.com (Edjunior Barbosa Machado), gdb-patches@sourceware.org In-Reply-To: from "Luis Machado" at Aug 23, 2016 11:26:12 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16082317-0032-0000-0000-00000200167B X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16082317-0033-0000-0000-00001C7DD33F Message-Id: <20160823170619.2D2C75BCB@oc7340732750.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-08-23_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608230170 X-SW-Source: 2016-08/txt/msg00236.txt.bz2 Luis Machado wrote: > On 08/23/2016 11:17 AM, Carl E. Love wrote: > > 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. > > Is this the case for all Power ABI's or only server? I wonder what the > impact would be on Power embedded. This doesn't really have anything to do with the ABI. As I said in the other email, the only effect of set_gdbarch_deprecated_fp_regnum these days is to affect what value GDB prints for $fp. This has really no meaning for anything except that MI front ends use it to identify stack frames: you examine a frame's $fp value, and use it as argument to the -var-create MI command in order to create a variable bound to this frame. (And even that usage is really questionably, and only remains in there to avoid incompatible changes in the interface. The "natural" way these days to identify a frame would be via its frame ID.) For this to work, the value of $fp must be the value of get_frame_base_address, which means set_gdbarch_deprecated_fp_regnum must not be used. And in fact basically no targets do use it, except for rs6000 and frv, both of which seem to be just incorrect. (Note that in any case, the rs6000 back end sets deprecated_fp_regnum to 1, which has never been the *frame pointer* register in any ABI, even those that -sometimes- use one. In fact, it is the *stack pointer* register ...) (Also note that there is a second remaining use of deprecated_fp_regnum, in legacy_virtual_frame_pointer. This whole routine is really a hack and probably doesn't work in any except the most trivial circumstances. Even so, Carl's change is a no-op for legacy_virtual_frame_pointer, since if deprecated_fp_regnum isn't set, it will fall back to sp_regnum, which is in fact also register 1 on rs6000.) Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com