From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114669 invoked by alias); 23 Aug 2016 17:19:42 -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 114643 invoked by uid 89); 23 Aug 2016 17:19:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Luis, love, affect 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; Tue, 23 Aug 2016 17:19:40 +0000 Received: from svr-orw-fem-04.mgc.mentorg.com ([147.34.97.41]) by relay1.mentorg.com with esmtp id 1bcFMP-0004LN-1t from Luis_Gustavo@mentor.com ; Tue, 23 Aug 2016 10:19:37 -0700 Received: from [134.86.105.206] (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.3.224.2; Tue, 23 Aug 2016 10:19:36 -0700 Reply-To: Luis Machado Subject: Re: [PATCH] Fix for gdb.base/pc-fp.exp. References: <20160823170619.2D2C75BCB@oc7340732750.ibm.com> To: Ulrich Weigand CC: "Carl E. Love" , Pedro Alves , Ulrich Weigand , Edjunior Barbosa Machado , From: Luis Machado Message-ID: <8507525d-035f-8fb2-d73e-2285d5bb276b@codesourcery.com> Date: Tue, 23 Aug 2016 17:19:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160823170619.2D2C75BCB@oc7340732750.ibm.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00237.txt.bz2 On 08/23/2016 12:06 PM, Ulrich Weigand wrote: > 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 > Fair enough. I was just checking what the outcome would be with Power Embedded and if it had been tested, since the original mail doesn't make it explicit what the failure mode is, nor what specific test is failing.