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

Mark Kettenis
2010-12-09T11:06:44Z

> 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.