Re: [RFA] mips 32/64 register/stack fix

[Michael Snyder <msnyder@redhat.com>]

Andrew Cagney wrote:
>> 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
> 
> 
>  >= 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?
> 
> 
> Hasn't this all come up before?
> 
> It's the register size of the underlying ISA, on top of which the ABI is 
> implemented.  I think I'll rename mips_regsize and mips_saved_regsize to 
> clarify this.
> 
>> 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).
> 
> 
> It does?  With the above it should always print a 32-bit GPR reflecting 
> the 32-bit ABI.  If you think it should display something else, look at 
> user-regs which lets you implement registers using the frame register 
> values (something psuedo registers can't handle).

I've got a build -- I'll try your patch and let you know how it behaves.
Are there any particular things you'd like me to check (eg. info reg),
aside from the problem that got me on this in the first place?