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

Daniel Jacobowitz
2007-06-12T18:25:13Z

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.