This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] Target-described register support for MIPS
On Tue, 12 Jun 2007, Daniel Jacobowitz wrote:
> > 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.
Hmm, it looks like they may have been defined so that some weird
handcoded assembly works for both o32 and n32 by using $t0-$t3 and
$ta0-$ta3 -- note how the definitions are swapped for the two ABIs.
But the names make no sense for o32 -- "ta" stands for
"temporary/argument" and these are obviously not argument registers. I do
not recall seeing any code using these names anyway and portable code will
probably refer to the registers by numbers as $4-$15 (once you have
recorded or discarded the arguments you are free to use all of these
registers as temporaries anyway), possibly hiding them under some
preprocessor macros. And GCC does not care.
> > 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
Well, "The MIPS64 Privileged Resource Architecture" manual is pretty
clear which cp0 registers are 64-bit and which are 32-bit, and the rest is
in "The MIPS64 Instruction Set" manual (revisions 2.50 at the very least;
I have not checked whether earlier revisions were clear on this matter).
> 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.
Sure.
> > 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.
I have got code doing this already which I hope I have got right.
Therefore the only issue that remains is converting it to this new
framework.
Maciej