> BTW, the raw floating point registers are still accessible. Doing
> "info registers raw" will display all of the raw registers. Or, if
> you know the names of the registers you want to display, you can do,
> e.g, "info registers raw_f20".
Hmm, is this necessary? Confusing? ``maint print
{raw-,cooked-,}registers'' are already available and provide access to
the underlying values.
Maybe we need to name the prefix something different than "raw_"?
Whatever we call them, I think it's still useful to have names
associated with them. E.g, you can do any of the following:
print $raw_f20
print/x ($raw_f20 >> 32)
set $raw_f20=0xbadbeef
Should there be separate raw and cooked num structures?
> +struct mips_regnums
> + {
> + int fp0_regnum; /* First floating point register. */
> + int fplast_regnum; /* Last floating point register. */
> + int last_arg_regnum; /* Last general purpose register used for
> + passing arguments. (a0_regnum is the
> + first.) */
> + int first_fp_arg_regnum; /* First floating point register used for
> + passing floating point arguments. */
> + int last_fp_arg_regnum; /* Last floating point register used for
> + passing floating point arguments. */
> + int zero_regnum; /* The zero register; read-only, always 0. */
> + int v0_regnum; /* Function return value. */
> + int a0_regnum; /* First GPR used for passing arguments. */
> + int t9_regnum; /* Contains address of callee in PIC code. */
> + int sp_regnum; /* Stack pointer. */
> + int ra_regnum; /* Return address. */
> + int ps_regnum; /* Processor status. */
> + int hi_regnum; /* High portion of internal multiply/divide
> + register. */
> + int lo_regnum; /* Low portion of internal multiply/divide
> + register. */
> + int badvaddr_regnum; /* Address associated with
> + addressing exception. */
> + int cause_regnum; /* Describes last exception. */
> + int pc_regnum; /* Program counter. */
> + int fcrcs_regnum; /* FP control/status. */
> + int fcrir_regnum; /* FP implementation/revision. */
> + int first_embed_regnum; /* First CP0 register for embedded use. */
> + int last_embed_regnum; /* Last CP0 register for embedded use. */
> + int prid_regnum; /* Processor ID. */
> + };
> +
> +const struct mips_regnums *mips_raw_regnums (struct gdbarch *gdbarch);
> +const struct mips_regnums *mips_cooked_regnums (struct gdbarch *gdbarch);
or at least keep things like "last_arg_regnum" out this space (they only
belong in one of the two spaces). Having them appear in both makes it
too easy to do the wrong thing.
Actually, I think it's useful for the layout raw and cooked regnum
structs to be identical. When initializing the cooked regnum struct,
we can do so via a single assignment:
/* For many registers, the cooked and raw register numbers are the same. */
tdep->cooked_regnums = tdep->raw_regnums;
/* Cooked regnum initializations that differ follow... */
The fact that the structs were identical made it easy and elegant to
define the reg_name() function which is used twice by mips_register_name(),
once for cooked register numbers, and a second time (assuming no suitable
cooked name was found) for the raw numbers. If the layout of the cooked
and raw structs were different, I'd need two separate functions with nearly
identical functionality. Ditto for mips_dump_regnums().
I think that you definitely want "last_arg_regnum" and
"last_fp_arg_regnum" to appear in both structs. At the moment, the
various MIPS *_push_argument() code uses the register names from the
raw regnums struct. I think it may be desirable at some point to make
this code use cooked regnums instead. (It will hopefully simplify a
bunch of code that worries about shifting values to the correct
position within a register.) For the floating point registers, where
the cooked and raw numbers are actually different, we would like
"first_fp_arg_regnum" and "last_fp_arg_regnum" to actually refer to
numbers within this space.