Re: Register numbers on hppa64

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> OK, this is a mess....:)
> 
> 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)

GCC regno 32 is fr4.  fr0 through fr3 aren't known to GCC.  So, we
actually have:

72, 74, ...: fr4, fr5, ...

This appears compatible with the gdb mapping.

> 60: sar

I believe that sar is 32 in the gcc dbx mapping.

> 2) gcc dwarf frame:
> unity mapping, so:
> 0-31: r0-r31
> 32-59: fr4-fr31
> 60: sar

This can't change (at least not easily).  This is tied to the
allocation of the dwarf_reg_size_table.s

The only way this can change is by adding the control and space
registers that GCC doesn't currently know about to GCC's register
tables.  This will impact performance to some extent.  There's
also no easy way to use these registers as they are mostly priviledged
or require special access techniques.

> 3) gdb
> 0-31: r0-r31
> 32-63: sar, pcoqh, pcsqh, other "special" registers
> 64-95: fr0-fr31
> 
> 4) HP compilers
> ???

This doesn't matter since HP uses a proprietary debug format.

I believe that the dbx mapping generally corresponds to the ordering
used by HP for fp_int_block_t, __reg32_t and __reg64_t in the save state.
However, the introduction of PA 2.0 made the save state more complex.
See the definition for struct save_state in pa/save_state.h.  Thus,
numbering compatibility with the save state probably isn't as useful
as it once once.

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

The current gcc numbering scheme has also been there for a long time.

At the moment, I don't see a reason to change the number scheme anywhere.
It seems that if there is a problem, it's in gdb (dbx vs. dwarf numbers).

Adding unused registers to gcc register tables isn't going to help
performance and it might break exception support if code from two GCC
versions is linked together.  We can define DWARF_FRAME_REGISTERS if
we need more frame registers (e.g., to restore the floating-point
state or 64-bit registers in 32-bit mode).  However, at the moment,
the unwind hooks to do this aren't there.

One bit in gcc bothers me.  If we didn't define DWARF_FRAME_REGNUM
(i.e., used the dbx default), it appears we could map the dbx numbers
to frame numbers using DWARF2_FRAME_REG_OUT.  The two techniques
appear redundant unless we actually need to define DWARF2_FRAME_REG_OUT
to map dbx numbers to frame numbers (i.e., the documentation is
wrong about the numbers being collected using DWARF_FRAME_REGNUM).
In the rs6000 sysv4.h case, DWARF_FRAME_REGNUM is also the gcc hard
registers but it appears that the ABIs mandate numbers for .debug_frame,
so a remapping is needed.  In our case, we don't have an ABI...

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

I guess this was the result:

2004-01-21  Alan Modra  <amodra@bigpond.net.au>

        * config/rs6000/sysv4.h (DWARF2_FRAME_REG_OUT): Define.
	* dwarf2out.c (output_cfi): Map regs using DWARF2_FRAME_REG_OUT.
	* doc/tm.texi (DWARF_FRAME_REGNUM, DWARF2_FRAME_REG_OUT): Document.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)