Re: SH5 compact register numbering in gcc -> gdb interface - include/elf/sh.h ?

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

ezannoni@redhat.com wrote:
> 
> Joern Rennecke writes:
>  > To give gcc and gdb a common interface, it is best put into a header file that
>  > but
>  > gdb/sh-tdep and gcc/config/sh/sh.h (can) include.
>  >
>  > I thought of putting it into include/elg/sh.h, since elf is now the predominant
>  > object format for SH gcc.  Or should we start something like an include/dwarf
>  > directory?
>  > But then, it's not strictly dwarf either, since these register numbers are
>  > also used for stabs debugging info (in the SH1..SH4 coff toolchain, or if
>  > you ask specifically for stabs.)
>  >
> 
> I think include/gcc-sh64.h or include/gdb-sh64.h could be OK. Would match the
> include/sim-sh64.h file.
> 
>  > --- ../include/elf/sh.h      Thu May  9 22:22:18 2002
>  > *************** START_RELOC_NUMBERS (elf_sh_reloc_type)
>  > *** 218,221 ****
>  > --- 218,247 ----
>  >     RELOC_NUMBER (R_SH_64_PCREL, 255)
>  >   END_RELOC_NUMBERS (R_SH_max)
>  >
>  > + enum
>  > + {
>  > +   SH_DEBUG_INFO_R0 = 0,
>  > +   SH_DEBUG_INFO_PR = 17,
>  > +   SH_DEBUG_INFO_GBR = 18,
>  > +   SH_DEBUG_INFO_MACH_BIG = 20, SH_DEBUG_INFO_MACL, SH_DEBUG_INFO_MACH_LITTLE,
> 
> This will break gdb. Register 22 ir SR. What are these registers?

gcc does not emit debug information for SR - if it was encountered in
DBX_REGISTER_NUMBER, the compiler would abort.  So we don't actually have a
number
allocated in the interface right now, and if we need one, we are free to choose
any.

> Doesn't SH have only mach and macl?

Yes, it has only mach and macl.  But you could hold a 64 bit value in this
register
pair, in which case MACH always holds the high part and MACL holds the low part.
So the idea is to use SH_DEBUG_INFO_MACH_BIG for big endian, and
SH_DEBUG_INFO_MACH_LITTLE for little endian.  This way, it is clear where low
and high
part are.  both SH_DEBUG_INFO_MACH_BIG and SH_DEBUG_INFO_MACH_LITTLE are then
mapped
to gdb's MACH.  Note that SH_DEBUG_INFO_MACH_BIG is the old MACH number, and
SH_DEBUG_INFO_MACL is the old MACL number, so we have full backwards
compatibility.
Having both this backwards compatibility and the ability to represent a 64 bit
value
in MACH/MACL for little endian was the point of using 22 for
SH_DEBUG_INFO_MACH_LITTLE.

>  > +   SH64_DEBUG_INFO_R0 = 0,
>  > +   SH64_DEBUG_INFO_TR0 = 68,
>  > +   SH64_DEBUG_INFO_FR0 = 77,
>  > +   SH64_DEBUG_INFO_T_C = 19,
>  > +   SH64_DEBUG_INFO_XF0_C = SH64_DEBUG_INFO_FR0 + 16,
>  > +   SH64_DEBUG_INFO_FPUL_C = SH64_DEBUG_INFO_FR0 + 32,
>  > +   SH64_DEBUG_INFO_R0_C = 141,
>  > +   SH64_DEBUG_INFO_GBR_C = 157,
>  > +   SH64_DEBUG_INFO_MACH_C_BIG, SH64_DEBUG_INFO_MACL_C,
>  > +   SH64_DEBUG_INFO_MACH_C_LITTLE,
>  > +   SH64_DEBUG_INFO_PR_C, SH_DEBUG_INFO_FPSCR_C
>  > + };
>  >   #endif
> 
> What is the advantage of reusing media numbers for compact registers?

The numbers are reused where the registers are actually identical.  Thus,
there is actually less work for gcc and gdb to encode and decode these
registers.

> This also wouldn't work with the current code, because it is assumed
> that the register sets are disjoint. I see that you have made disjoint

I don't know what you need disjoint registers for, when the size and
location of the register is the same in either mode.  What part of the
code makes assumptions about further disjointness?
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330