This is the mail archive of the
mailing list for the GCC project.
Re: SH5 compact register numbering in gcc -> gdb interface
- From: Elena Zannoni <ezannoni at redhat dot com>
- To: joern dot rennecke at st dot com
- Cc: gcc at gcc dot gnu dot org, gdb at sources dot redhat dot com, aoliva at redhat dot com,ezannoni at redhat dot com, bje at redhat dot com, ac131313 at cygnus dot com
- Date: Wed, 1 May 2002 20:52:03 -0400
- Subject: Re: SH5 compact register numbering in gcc -> gdb interface
- References: <3CCED903.294513BE@st.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-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
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,
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.
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)) \