This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Register numbers on hppa64


> Date: Sat, 26 Nov 2005 15:27:39 +0800
> From: Randolph Chung <randolph@tausq.org>
> 
> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]