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

[Joern Rennecke <joern dot rennecke at st dot com>]

ezannoni@redhat.com wrote:
> 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.

Right, so we do need the general purpose register to have different
numbers, because of their different size.  The size shouldn't really
matter for single integer values inside a register, but it does when you
need more than one register for SHcompact, or you are describing register
saves / restores.

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

It needs to be extensively rewritten anyways to accomodate the disjoint
register numbers for SH1-4 / SHmedia simulators, and to fix numerous bugs.
This rewrite becomes indeed simpler if we make the interface a bit more
straightforward.

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

sh-tdep has a lot of hardcoded 'knowledge' how simulator numbers relate
to the layout of th register cache.  Moreover, we should loose all the
tdep->FOO_REGNUM stuff where the value is actually a constant according
to the simulator interface.

> 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

fr0 .. fr15 are really the same in SHcompact and SHmedia, so there is no
reason to use different numbers in the gcc -> gdb interface.  It is convenient
to have different numbers in the gtdb <-> sim interface since that allows
you to keep the old numbers for SH1-SH4, while having contigous numbers
for fr0..fr63 for SHmedia.
dr0..dr14 / fv0 .. fv12 don't even exist as separate registers, but are
just a different view of fv0..fv15.  There is no reason to make them part
of the gcc -> gdb or gdb <-> sim interface, nor is there any point in
providing disjoint pseudo registers for media and compact mode in gdb itself.

PC, T, GBR and FPSCR are not actually in the gcc -> gdb interface.
If you wanted to put a value into T_C, this can be described as
putting it into R19, so there so no point in even reserving a number.
I can imagine circumstances where you would want to push GBR or
FPSCR in the prologue, so it might make sense to have a number for them.

FPUL is the same size as FR32, so it makes sense to describe it as FR32,
since that is what it really is.

PR would only appear as a saved register, but I gather that gdb needs to know
the size it has been saved in, so it makes sense to have a separate number.

MACH and MACL are a rather unique problem.  When you put a 64 bit value into
them, you can only describe this properly if you are using big endian.
This could be fixed e,g, by having a third register, i.e.
big endian MACH / MACL / little endian MACH.

 19     t_c

 77     fr0, fr1, fr2,  fr3,  fr4,  fr5,  fr6,  fr7,
 85     fr8, fr9, fr10, fr11, fr12, fr13, fr14, fr15,
 93     xf0, xf1, xf2,  xf3,  xf4,  xf5,  xf6,  xf7,
101     xf8, xf9, xf10, xf11, xf12, xf13, xf14, xf15,
109     fpul_c
	
141     r0_c, r1_c, r2_c,  r3_c,  r4_c,  r5_c,  r6_c,  r7_c,
149     r8_c, r9_c, r10_c, r11_c, r12_c, r13_c, r14_c, r15_c,
157     gbr_c, mach_c (big endian), macl_c, mach_c (little endian), pr_c,
fpscr_c	
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330