Messages in this thread | | | Date | Mon, 18 Apr 2016 19:09:42 +0100 | From | "Maciej W. Rozycki" <> | Subject | Re: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits |
| |
On Mon, 18 Apr 2016, Ralf Baechle wrote:
> I extracted a rather simple test case: > > $ echo >> testcase .s << EOF > .set mips3 > dli $2, 0x9000000080000000 > EOF > $ mips-linux-as -mips3 -march=r4600 -o testcase.o testcase.s > testcase.s: Assembler messages: > testcase.s:2: Error: number (0x9000000080000000) larger than 32 bits > $ mips-linux-as -mips4 -march=vr5000 -o testcase.o testcase.s > $
Ah, and if you use `.set mips4' instead, then the symptoms reverse.
The thing is that to match some software's (such as ours) requirements an ISA override -- as a side effect -- relaxes ABI restrictions on certain operations. E.g. the DLI macro and its 64-bit immediate argument are not valid in the o32 ABI. When no actual override happens, such as with `-march=r4600' which already implies `mips3' for the ISA, the side effect is lost:
/* The use of .set [arch|cpu]= historically 'fixes' the width of gp and fp registers based on what is supported by the arch/cpu. */ if (mips_opts.isa != prev_isa)
> I can trigger the error message with vanilla 2.25 and 2.26 but not 2.24.
The regression has come with:
commit 919731affbef19fcad8dddb0a595bb05755cb345 Author: mfortune <matthew.fortune@imgtec.com> Date: Tue May 20 13:28:20 2014 +0100
Add MIPS .module directive
-- previously the side effect was unconditional, even if no ISA change resulted.
Matthew, this functional change was not mentioned in the review: <https://sourceware.org/ml/binutils/2014-05/msg00179.html> -- what was the rationale behind it? Do you expect any issues if we revert to old semantics?
Maciej
| |