Re: [RFC] mips-tdep.c: Update mips_register_to_value(), et al...

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Wed, 8 Dec 2010 16:46:57 -0700
> From: Kevin Buettner <kevinb@redhat.com>
> 
> Below is yet another patch that fixes a problem arising from the
> simulator catching UNPREDICTABLE behavior.   This time though, it's
> for mips64 targets that are being run in 64-bit mode.  (My earlier
> two patches dealt with 32-bit mode.)
> 
> When executing the command "set variable l = 4", GDB is writing to the
> low 32 bits of the register containing `l'.  The value was previously
> -1.  Writing only the low 32 bits with a positive value causes a
> sign mismatch between the lower 32 bits and the upper 32 bits which
> eventually causes the sim to abort back to GDB.  The instruction
> that causes the abort is the 32-bit addu instruction:
> 
> => 0xffffffff800203a4 <add_int+20>:     addu    v0,v1,v0
> (gdb) p/x $v0
> $8 = 0xfffffffffffffffe
> (gdb) p/x $v1
> $9 = 0xffffffff00000004
> (gdb) si
> UNPREDICTABLE: PC = 0x800203a4
> 
> (If the 64-bit daddu had been used instead, this abort would not have
> been triggered.)
> 
> The patch below adds a case to mips_value_to_register() to ensure that
> sign extension is performed when writing a value shorter than 64-bits
> to a 64-bit register.  It updates mips_convert_register_p() and
> mips_register_to_value() as well.
> 
> Comments?

So what if we were adding a 32-bit unsigned integer to a 64-bit
integer signed integer?  Then it would presumably be using the 64-bit
daddu instruction, and sign extending the 32-bit value when placing it
into the register would yield the wrong result wouldn't it?

> (Can anyone think of better names for the two new functions that I
> introduced?)

Yeah, they're pretty horrific.