From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15296 invoked by alias); 26 Nov 2005 15:18:44 -0000 Received: (qmail 15272 invoked by uid 22791); 26 Nov 2005 15:18:43 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 26 Nov 2005 15:18:41 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id jAQFIRd7031129; Sat, 26 Nov 2005 16:18:27 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id jAQFIQlW010554; Sat, 26 Nov 2005 16:18:26 +0100 (CET) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id jAQFIN2K022588; Sat, 26 Nov 2005 16:18:23 +0100 (CET) Date: Sat, 26 Nov 2005 15:54:00 -0000 Message-Id: <200511261518.jAQFIN2K022588@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: randolph@tausq.org CC: gdb@sources.redhat.com, dave@hiauly1.hia.nrc.ca, brobecker@adacore.com In-reply-to: <43880E6B.8060901@tausq.org> (message from Randolph Chung on Sat, 26 Nov 2005 15:27:39 +0800) Subject: Re: Register numbers on hppa64 References: <200511260253.jAQ2rP7Z021130@hiauly1.hia.nrc.ca> <43880E6B.8060901@tausq.org> 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/msg00576.txt.bz2 > Date: Sat, 26 Nov 2005 15:27:39 +0800 > From: Randolph Chung > > OK, this is a mess....:) 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 > 2) gcc dwarf frame: > unity mapping, so: > 0-31: r0-r31 > 32-59: fr4-fr31 > 60: sar > > 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. > Joel, does your GNAT C compiler output something different from the > above? :-) > > Obviously this will not work.... > > The gdb numbering scheme seems to be there for a long time. I don't know > if this is the way HP numbers registers in their debug format. Does > anybody have a pointer to this information? 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. > I see that in late 2003/early 2004 there was a discussion about archs > with mismatched "dbx register numbers" vs "dwarf CFI register numbers" > on gcc@gcc.gnu.org and gdb-patches@gcc.gnu.org. Back then the discussion > was about ppc64, although i was not quite sure what was the conclusion > of those discussions. hppa64 is in a similar situation. Well, the ppc64 situation was a real mess, because the GCC people screwed up, and used *their* internal mapping instead of the officially documented numbers defined in the ELF ABI for DWARF2, and this mapping was also used for GCC's exception handling info (which is based on DWARF2). I'm not sure at all whether the issue has been resolved. For hppa64 the situation is much better since... > Any comments or suggestions on how to sort this out? Should I just > change gdb to match what gcc outputs? Should we change gcc to match what > gdb expects? (safer?) ...we (GDB) are the ones that screwed up. Fortunately it's really easy to fix things. We just need to provide the appropriate xxx_reg_to_regnum functions in the acrhitecture vector. Actually the fix seems to be partly implemented already: there's a #ifdeffed out hppa_dwarf_reg_to_regnum in hppa-linux-tdep.c. I think it should be moved to hppa-tdep.c, and a 64-bit version should be created. Anyway, see i386-tdep.c for a complicated example of how registers are mapped differently for several debugging formats and executable formats. Mark