Re: [rfc] Target-described register support for MIPS

[Daniel Jacobowitz <drow at false dot org>]

On Tue, Jun 12, 2007 at 07:14:29PM +0100, Maciej W. Rozycki wrote:
> > +/* Aliases for o32 and most other ABIs.  */
> > +const struct register_alias mips_o32_aliases[] = {
> > +  { "ta0", 12 },
> > +  { "ta1", 13 },
> > +  { "ta2", 14 },
> > +  { "ta3", 15 }
> > +};
> 
>  Hmm, these look wrong -- no "ta" registers have been defined for old 
> ABIs.

OK, I'll drop them.  They came from O32_SYMBOLIC_REGISTER_NAMES in
gas/config/tc-mips.c.

> > +      /* FIXME drow/2007-05-17: The FPU should be optional.  The MIPS
> > +	 backend is not prepared for that, though.  */
> 
>  I do certainly have some patches covering this area -- please check with 
> me before commencing any related work.  There are quite a lot of FPU 
> configurations to handle too, including MIPS32r2 processors with 64-bit 
> FPU and MIPS16 code using hard float.

Great.  I'm not planning to work on it right now, but I expect I'll be
back.

> > +<feature name="org.gnu.gdb.mips.cp0">
> > +  <reg name="status" bitsize="64" regnum="32"/>
> > +  <reg name="badvaddr" bitsize="64" regnum="35"/>
> > +  <reg name="cause" bitsize="64" regnum="36"/>
> > +</feature>
> 
>  Hmm, "status" and "cause" are generally 32-bit -- for the MIPS64 
> architecture dmfc0/dmtc0 on such registers are defined as yielding 
> unpredictable results (and I think at least one implementer did take this 
> seriously), so they should be accessed as 32-bit registers.  For legacy 
> chips the results may vary too.  The cause register is 64-bit for the 
> R8000 IIRC, but whether it matters should probably be verified by an IRIX 
> user.

Hmm.  I only marked them 64-bit because (the manual wasn't entirely
clear and) that's how big they were in GDB previously.  We can allow
32-bit registers here, but it will take some surgery in the rest of
mips-tdep.c.  Fortunately it's not an incompatible change, so I hope
you'll forgive me for putting it off.

>  These are just minor nits.  Overall I like the change, though to cover 
> all the optional subsets of cp0 that MIPS32 and MIPS64 specs define quite 
> a lot of DTDs will have to be created.

(documents, not DTDs.)  Yes, probably.  It may be that there's a more
sensible way to define the subsets of cp0; they may all go in a "cp0"
feature, and then let GDB determine the available subsets based on
which registers are included.  When you have a chance to look at it
closer, we can work something out - I don't know enough about it.

-- 
Daniel Jacobowitz
CodeSourcery