[PATCH, MIPS, OPCODE] mips-dis.c build error
Michael Eager
eager@eagerm.com
Fri Mar 8 20:12:00 GMT 2013
On 03/08/2013 11:29 AM, Maciej W. Rozycki wrote:
> On Fri, 8 Mar 2013, Michael Eager wrote:
>
>> I get an error complaining about mismatched unsigned/signed
>> initialization in opcpode/mips-dis.c while building gdb using
>> gcc-4.7.2.
>>
>> Here is a simple fix:
>>
>> ChangeLog
>> * opcodes/mips-dis.c (print_insn_args): Modify def of reg.
>>
>> Index: opcodes/mips-dis.c
>> ===================================================================
>> RCS file: /cvs/src/src/opcodes/mips-dis.c,v
>> retrieving revision 1.98
>> diff -u -r1.98 mips-dis.c
>> --- opcodes/mips-dis.c 13 Feb 2013 17:09:09 -0000 1.98
>> +++ opcodes/mips-dis.c 8 Mar 2013 18:32:32 -0000
>> @@ -1273,7 +1273,9 @@
>> case 'U':
>> {
>> /* First check for both rd and rt being equal. */
>> - unsigned int reg = GET_OP (l, RD);
>> + unsigned int reg;
>> +
>> + reg = GET_OP (l, RD);
>> if (reg == GET_OP (l, RT))
>> infprintf (is, "%s", mips_gpr_names[reg]);
>> else
>
> Hmm, I find it suspicious that l is signed in the first place -- what the
> heck for is a machine instruction word held in a signed variable?
> There's no arithmetic meaning to the word, it's just a bit pattern,
> unsigned would seem more consistent to me, e.g. if you shift the major
> opcode field right so that it could index a table (the usual
> interpretation), why should an arithmetic shift operation cause the MSB to
> be kept and copied across, requiring an extra masking operation?
Agreed.
> Nothing wrong with your change, but perhaps we should fix the cause
> instead?
There are many places in the file where a signed int is used hold a
insn or some piece of one, like the opcode. Fixing all of the places
where int should be replaced by unsigned, replacing all of the %d's in
formats with %u, and changing function declarations, would amount to
several dozens of modified lines. I opted for a one line change.
--
Michael Eager eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
More information about the Binutils
mailing list