This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Use correct register names for MIPS n32/n64 ABIs


For an Irix 6 target, when debugging an o32 program, gdb does not
provide the correct register names when using "info registers".
It does however, use the correct names for n32/n64.  Conversely, for
all other MIPS targets, o32 register names are always used regardless
of the ABI.

+ if (i < 32 && (abi == MIPS_ABI_N32 || abi == MIPS_ABI_N64)) + return mips_n32_n64_gpr_names[i]; + else + return mips_processor_reg_names[i];

Having mips_register_name() only handle half the ABIs (n32/n64) is, I think, weird.


The patch below causes the correct ABI-dependent register names to be
used.

I considered at least one other approach for fixing this problem. I
considered providing new register name arrays for each of the ABIs,
but that seemed unwieldy, and quite unnecessary too since the GPR
register numbers are always 0-31. Also, all mips cores (that gdb
knows about) agree on what these names should be for the o32 ABI. As
such, it seemed easier to remap just the names of the GPRs in
mips_register_name().


Another follow on patch to this one would be to encode the knowledge
of what the GPRs should be entirely within mips_register_name() and
relegate the register name arrays to describing (only) the names of
registers whose numbers are 32 or greater.  (I'll wait to do this
until I find out the reaction to the patch below.)

Can you please just do this, and consider it pre-approved. When (regnum < 32) have mips_register_name() always generate the name directly, only refering to mips_processor_reg_names[] when i>=32.


A bounds check on mips_processor_reg_names[i] probably wouldn't hurt.

Andrew



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]