Re: check mips abi x linker emulation compatibility

[Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>]

Alexandre Oliva wrote:
> We currently fail to reject attempts to link say mips ELF64 object
> files using elfn32 or elf32 emulations, or N32 ELF32 objects using
> elf32 or elf64 emulations.  This patch fixes this problem without
> introducing regressions on mips-linux-gnu, but it's a disaster for the
> linker testsuite in mips64-linux-gnu: the assembler generates ABI-less
> elf32 code by default, which the linker rightfully recognizes as
> elf32, thus rejecting to link it using the default n32 emulation.  I'm
> thinking one way to fix the problem is to get the assembler to
> actually choose an ABI as default.  Currently it just leaves mips_abi
> set to NO_ABI through to the end of the compilation, which makes it
> fail to set any of the ABI flag bits.
>
> I'm thinking of doing it with
> some triple-specific machinery, akin to what we currently use to set
> MIPS_DEFAULT_64BIT.
> 
> I was thinking of doing the same change for Irix as well, however, now
> I realize that the IRIX assembler doesn't default to n32, unlike the
> compiler.  I'm not entirely sure on how to proceed: it seems that our
> assembler matches IRIX's behavior,

It's probably not due to IRIX compatibility. The ABI flags weren't
defined in the (o32) MIPS ABI supplement, E_MIPS_ABI_O32 was invented
later. Just ignoring the flags until specifically requested avoided
breakage.

> but the linker doesn't, the main
> difference being that we fail to detect the emulation to be used from
> the input object files.  I've no idea of how much effort it would be
> to get GNU ld to do that, and I'm not entirely sure it's worth the
> effort.
> 
> Meanwhile, I'm considering the possibility of switching the linker
> default ABI on mips64-linux-gnu to o32, at least to get linker tests
> to pass.  Comments?

IMHO it's better to change the GAS default to n32 for mips64-unknown-linux
and mips-sgi-irix6, because that is/will be the most heavily used ABI
variant on NewABI capable systems.


Thiemo