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


> 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)


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