On Mon, 18 Apr 2016, Maciej W. Rozycki wrote:
> 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)
It's worse yet actually, as operations such as `.set pop' and `.set
mips0' may not restore the ABI restrictions, possibly leading to wrong
code generation elsewhere, generally in handcoded assembly only. This can
be illustrated with a program like:
.set push
.set mips3
dli $2, 0x9000000080000000
.set mips0
dli $2, 0x9000000080000000
.set mips3
.set pop
dli $2, 0x9000000080000000
-- try building it with `-mips3' and `-mips4' to see how it fails or
succeeds to assemble all the three DLI macros respectively, where it is
supposed to succeed with the first macro only and fail with the other two
in both cases.
I have a fix in the works and to have it integrated upstream I just need
to accompany it with suitable cases -- like the fragment above -- for the
GAS testsuite. I'll send an update when it's ready.
Maciej
