Re: SH5 compact register numbering in gcc -> gdb interface

[Elena Zannoni <ezannoni at redhat dot com>]

Joern Rennecke writes:
 > The numbers currently used to encode registers in the debug information
 > for SH5compact seem quite arbitrary.  I see that they correspond
 > to the current pseudo register scheme in gdb, but this is going
 > to change when a unified interface for SH and SH64 is created.
 > What I have in mind for the simulator interface is to keep the
 > current SH1-SH4, SH[3]-DSP register numbers, (and also keep the
 > corresponding gdb pseudo register numbers), and start the SH64
 > numbers at 128.
 > The SHcompact simulator register numbers can be the same as for SH4.
 > However, this exposes the arbitrariness of the gcc->gdb interface,
 > and I think now - before the integration of the simulator and gdb
 > port into the FSF sources - is our last chance to change it.
 > 

Hmmm, in theory the numbers in the debug info for sh5 don't need to be
the same as the gdb ones. In theory GDB could deal with this by defining
its own mapping with the macro DWARF2_REG_TO_REGNUM.

However this is only a piece of the puzzle... see below

 > The SHcompact registers are all mapped to SH5media registers,
 > and therefore it seems most natural to use the numbers used
 > for these SH5media registers also in SHcompact code - indeed,
 > this is currently already done for the general purpose registers.
 > The only odd one out is MACH, which resides in the upper 32 bit
 > of R17; for this I propose to use number 141.
 > This numbering also has the advantage that all SH5compact registers
 > except MACH can be encoded with LEB128 in a single byte.
 > 
 > compact reg current #   sh5 equiv    proposed #
 > -----------+-----------+------------+------------------
 > R0  .. R15     0 ..  15 R0   .. R15    0 ..  15
 > FR0 .. FR15  245 .. 260 FR0  .. FR15  77 ..  92
 > XD0 .. XD14  289 .. 296 DR16 .. DR30  93 .. 107 (odd only)
 > PR           241        R18           18
 > T            242        R19           19
 > GBR          238        R16           16
 > MACH         239        R17(high)    141
 > MACL         240        R17(low)      17
 > FPUL         244        FR32         109
 > 

If you change the compact registers numbers in the debug info to be
the same as the (or to reuse) numbers for sh media, then the gdb port
will be badly broken. (Never mind for the moment that the current
mapping is screwed up, I agree, but for opposite reasons to
yours...I'll explain in a second.)  The reason that the gdb port will
break is that gdb needs to know the ABI currently in use when
reading or writing a register, because the register sizes are
different. For this reason GDB relies on the the register numbers
being disjoint for compact and media modes.

Now, looking at the current mapping, the 2 sets are not disjoint, and
this is the reason for which gdb is failing some tests currently. I
hadn't closely looked at this mapping before, unfortunately.  In case
of general registers gdb gets very confused between compact and media
mode. It doesn't know how long the register is when trying to read the
value of a variable stored in a general register because the debug
information is exactly the same for the 2 modes. The only way to get
around this, which your re-mapping would also require, is to have
*always* available the PC of the frame relative to which we are
reading the register, because the PC being odd/even tells us which
ABI, and therefore which register size, is in use.  At this time I
have identified 2 places in GDB where I have a hack in place to work
around this overlap of register sets. However I haven't submitted the
hacks publicly, because they are pretty bad. Anyway, there are plenty
of other places where a PC value (i.e. a frame parameter) would need
to be added to gdb internal functions, to get this right. 

As far as the sh-tdep.c code goes, this also would have to be
extensively rewritten if the assumption that the register sets are
disjoint is dropped.

So, I would be opposed to such a change.

I don't think renumbering the simulator registers would have such a
devastating effect.

Anyway, I agree with you that the current version of the
SH_DBX_REGISTER_NUMBER is not the most logic arrangement.  The
floating point registers are mapped to a separate subset, but the
general registers are not. 

All the following registers should be mapped to a register
set disjoint from the sh media one.
Right now they are not.

SH COMPACT MODE (ISA 16)
221     r0_c, r1_c, r2_c,  r3_c,  r4_c,  r5_c,  r6_c,  r7_c,
229     r8_c, r9_c, r10_c, r11_c, r12_c, r13_c, r14_c, r15_c,
237     pc_c,
238     gbr_c, mach_c, macl_c, pr_c, t_c,
243     fpscr_c, fpul_c,
245     fr0_c, fr1_c, fr2_c,  fr3_c,  fr4_c,  fr5_c,  fr6_c,  fr7_c,
253     fr8_c, fr9_c, fr10_c, fr11_c, fr12_c, fr13_c, fr14_c, fr15_c
261     dr0_c, dr2_c, dr4_c,  dr6_c,  dr8_c,  dr10_c, dr12_c, dr14_c
269     fv0_c, fv4_c, fv8_c,  fv12_c

I believe something like this would work.

Elena


Index: sh.h
===================================================================
RCS file: /cvs/uberbaum/gcc/config/sh/sh.h,v
retrieving revision 1.137
diff -u -r1.137 sh.h
--- sh.h	3 Mar 2002 21:10:04 -0000	1.137
+++ sh.h	2 May 2002 00:49:21 -0000
@@ -2896,6 +2896,8 @@
 #define DBX_REGISTER_NUMBER(REGNO) \
   (GENERAL_REGISTER_P (REGNO) \
    ? ((REGNO) - FIRST_GENERAL_REG) \
+   ? ((REGNO) - FIRST_GENERAL_REG + (TARGET_SH5 ? (TARGET_SHCOMPACT ? 221 \
+                                                   : 0) : 0)) \
    : FP_REGISTER_P (REGNO) \
    ? ((REGNO) - FIRST_FP_REG + (TARGET_SH5 ? (TARGET_SHCOMPACT ? 245 \
 					      : 77) : 25)) \