From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22645 invoked by alias); 26 Nov 2005 18:31:43 -0000 Received: (qmail 22637 invoked by uid 22791); 26 Nov 2005 18:31:42 -0000 X-Spam-Check-By: sourceware.org Received: from hiauly1.hia.nrc.ca (HELO hiauly1.hia.nrc.ca) (132.246.100.193) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 26 Nov 2005 18:31:42 +0000 Received: from hiauly1.hia.nrc.ca (hiauly1.hia.nrc.ca [127.0.0.1] (may be forged)) by hiauly1.hia.nrc.ca (8.12.9-20030917/8.12.9) with ESMTP id jAQIVdqO014734; Sat, 26 Nov 2005 13:31:39 -0500 (EST) Received: (from dave@localhost) by hiauly1.hia.nrc.ca (8.12.9-20030917/8.12.9/Submit) id jAQIVckq014731; Sat, 26 Nov 2005 13:31:38 -0500 (EST) Message-Id: <200511261831.jAQIVckq014731@hiauly1.hia.nrc.ca> Subject: Re: Register numbers on hppa64 To: mark.kettenis@xs4all.nl (Mark Kettenis) Date: Sat, 26 Nov 2005 18:50:00 -0000 From: "John David Anglin" Cc: randolph@tausq.org, gdb@sources.redhat.com, brobecker@adacore.com In-Reply-To: <200511261719.jAQHJnTd015739@elgar.sibelius.xs4all.nl> from "Mark Kettenis" at Nov 26, 2005 06:19:49 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00586.txt.bz2 > It looks like we need some > GCC_DEVELOPERS_DONT_THINK_BEFORE_THEY_CODE_MAP_REG_TO_REGNUM mapping. > (sorry Dave) Sigh.... ~ > > I wrote that code... :) but I think it's actually wrong; for 32-bit we > > have a 1:1 mapping between what gcc outputs for "dbx" register numbers > > in dwarf debug mode and the gdb internal register numbering, so we > > shouldn't need this mapping function for 32-bit. > > No, even for 32-bit stuff there is a mapping: > > /* How to renumber registers for dbx and gdb. > > Registers 0 - 31 remain unchanged. > > Registers 32 - 87 are mapped to 72 - 127 > > Register 88 is mapped to 32. */ > > But you're right, it's not right to use this encoding for decoding > DWARF CFI since that uses the a different mapping (but that mapping > isn't 1:1). I believe that we have a 1:1 mapping between gcc's frame and dbx numbers at the moment. I haven't fully thought this through but the save state contains information that we don't currently copy to the frame state. We could record this frame state data if there was a way to restore it. Thus, I don't believe that gcc's sets of frame and dbx registers have to be the same. For example, there is no direct way in gcc to set the floating point status registers. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602)