From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7459 invoked by alias); 22 Dec 2010 22:05:59 -0000 Received: (qmail 7451 invoked by uid 22791); 22 Dec 2010 22:05:58 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_SOFTFAIL,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate7.uk.ibm.com (HELO mtagate7.uk.ibm.com) (194.196.100.167) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 22 Dec 2010 22:05:53 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate7.uk.ibm.com (8.13.1/8.13.1) with ESMTP id oBMM5osJ031657 for ; Wed, 22 Dec 2010 22:05:50 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oBMM5qwE3465450 for ; Wed, 22 Dec 2010 22:05:52 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oBMM5nA1025679 for ; Wed, 22 Dec 2010 15:05:50 -0700 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id oBMM5m4g025676; Wed, 22 Dec 2010 15:05:48 -0700 Message-Id: <201012222205.oBMM5m4g025676@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 22 Dec 2010 23:05:48 +0100 Subject: Re: [patch 2/2] Implement gdbarch hook user_register_name on ARM To: rearnsha@arm.com (Richard Earnshaw) Date: Thu, 23 Dec 2010 02:05:00 -0000 From: "Ulrich Weigand" Cc: yao@codesourcery.com (Yao Qi), gdb-patches@sourceware.org In-Reply-To: <1293039320.11190.9.camel@e102346-lin.cambridge.arm.com> from "Richard Earnshaw" at Dec 22, 2010 05:35:20 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2010-12/txt/msg00414.txt.bz2 Richard Earnshaw wrote: > Overall, I think it's just best if 'fp' is treated like any other > standard register alias on ARM and therefore that it always refers to > R11. If we really want a register alias that refers to the *current* > frame pointer register, then we need a new name that doesn't conflict > with anything in the current or previous ABIs. Maybe a > slightly-long-winded name like 'frame'? Well, the problem is that that "fp" itself has a fixed meaning in GDB. This shows up most problematically in the MI interface. When the MI user interface application wants to select a frame in certain MI commands, that frame has to identified via its "frame base" value. However, there is no defined way to *query* that value. Therefore, my understanding is that the MI frontends typically query the value of the standard "fp" register to retrieve this value. If an architecture back-end now goes and redefines what "fp" stands for, this will break this MI frontend convention ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com