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] |
On Wed, Apr 28, 2004 at 05:45:22PM -0400, Andrew Cagney wrote:
>Here's your tdep info: >{elf_flags = 1610625025, mips_abi = MIPS_ABI_EABI32,
I was looking to see if anything like that was present -> it is clearly identified as a 32-bit ABI binary.
I think the bug is in mips_register_type, the tail end should probably be changed to read something like:
else if (regnum >= NUM_REGS && gdbarch_tdep (gdbarch)->mips64_transfers_32bit_regs_p) /* The target, while using a 64-bit raw register buffer, is only transfering 32-bits of each integer register. Reflect this in the cooked/pseudo register value. */ return builtin_type_int32; else if (regnum > NUM_REGS
&& mips_saved_regsize (gdbarch) == 4) /* A 32-bit ABI such as o32 possibly running on a 64-bit ISA. */ return builtin_type_int32; else if (mips_regsize (gdbarch) == 8) /* 64-bit ISA. */ return builtin_type_int64; else /* 32-bit ISA. */ return builtin_type_int32;
Would you mind clarifying the reason for having mips_regsize, which is used in a number of other places, return a regsize based on the ISA?
This change to mips_register_type conveys the fact that we've only got 32 bits of data. But we'll choose to print (in info registers) a 64-bit wide field for each GPR if the binary is tagged E_MIPS_ARCH_64 | E_MIPS_ABI_EABI32, and a 32-bit field if it's tagged E_MIPS_ARCH_2 | E_MIPS_ABI_EABI32. Conceptually, I think we're interested in some combination of the available register size (-> a property of the target) and the size of registers known to the inferior program (-> unclear mix of its ABI and ISA).
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |