From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30405 invoked by alias); 26 Nov 2005 17:13:47 -0000 Received: (qmail 30397 invoked by uid 22791); 26 Nov 2005 17:13:45 -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 17:13:43 +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 jAQHDdqO024158; Sat, 26 Nov 2005 12:13:40 -0500 (EST) Received: (from dave@localhost) by hiauly1.hia.nrc.ca (8.12.9-20030917/8.12.9/Submit) id jAQHDcTw024157; Sat, 26 Nov 2005 12:13:38 -0500 (EST) Message-Id: <200511261713.jAQHDcTw024157@hiauly1.hia.nrc.ca> Subject: Re: Register numbers on hppa64 To: mark.kettenis@xs4all.nl (Mark Kettenis) Date: Sat, 26 Nov 2005 17:20:00 -0000 From: "John David Anglin" Cc: randolph@tausq.org, gdb@sources.redhat.com, brobecker@adacore.com In-Reply-To: <200511261518.jAQFIN2K022588@elgar.sibelius.xs4all.nl> from "Mark Kettenis" at Nov 26, 2005 04:18:23 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/msg00580.txt.bz2 > It's not too bad ;-). > > > Apparently we now have at least three different register numbering > > schemes for hppa64: > > > > 1) gcc "dbx": > > 0-31: r0-r31 > > 72-135: fr0-fr31 (odd numbers are not used) > > 60: sar > > gcc/config/pa/pa64-regs.h says: > > /* How to renumber registers for dbx and gdb. > > Registers 0 - 31 remain unchanged. > > Registers 32 - 59 are mapped to 72, 74, 76 ... > > Register 60 is mapped to 32. */ > > So it seems that the last line of your list should be: > > 32: sar Also, gcc register 32 is fr4, so the floating-point registers match the gdb numbers. Odd "floating-point" numbers aren't used. > > 3) gdb > > 0-31: r0-r31 > > 32-63: sar, pcoqh, pcsqh, other "special" registers > > 64-95: fr0-fr31 > > This is GDB's *internal* register mapping. On some targets we've been > careful and made that internal register mapping match the one used by > the "standard" compiler/debugger on that target, for most targets this > is not the case. > > > 4) HP compilers > > ??? > > I'm not even sure what debug format HP's 64-bit compilers use. The > fact that the dbx mapping is a bit weird, suggests that there has been > a system that used stabs with that register mapping once. Not sure if > that was HP-UX or the old BSD variant that ran on PA-RISC systems. I don't think stabs has been used with GCC on hppa64. > Since it's GDB's internal numbering it's perfectly well possible that > the numbering scheme isn't used by any debug format at all. I think > it's mostly dictated by the layout of "struct save_state" from HP-UX. > Could be that this is the numbering scheme used by HP though. That's also my impression. However, since PA 2.0, the layout of "struct save_state" is more complicated. In the 32-bit case, access depends on whether or not UseWideRegs (ssp) is true or not. It's not entirely clear how one would derive an unique numbering. Really, the issue seems to be converting the dbx and frame numbers to gdb's internal numbering. This is a nop for the dbx numbers but not for the frame numbers. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602)