The big-endian arm32 Linux builds are currently failing when the -mbig-endian and -fno-use-integrated-as flags are used and the assembler default is little endian. We are not registering that the clang -mbig-endian flag needs to be passed through to the assembler to override its default target. This also extends to the linker, where the presence of -mbig-endian or -mlittle-endian can affect the emulation and the output endianness.
This patch explicitly passes -EB or -EL to the linker and assembler to override the default endianness of the assembler and linker.
For Arm, the -mbig-endian and -mlittle-endian do not affect the Architecture in Triple::computeTargetTriple(), see Triple::getBigEndianArchVariant() and Triple::getLittleEndianArchVariant() for details. This means we need to account for it when
determining what linker emulation to use and which endian flag to pass to the assembler and linker. For AArch64 (and other targets) Triple::computeTargetTriple() will account for -mbig-endian and -mlittle-endian and alter the Arch field of the triple.
FIXME: While fixing this I note that giving the endianness in march does not override the endianness in the triple. This is not specific to -fno-integrated-as so if I write --target=arm-linux-gnueabihf -march=armebv7-a then the output is little endian. I've updated the targets in the test so that the target endian matches the march endianness.
I think that this behaviour is wrong for a couple of reasons:
- -march=armebv7-a should either give an error message if it disagrees with the triple or should override the triple.
- The GNU assembler doesn't understand eb in march so we should ideally not pass it through, or rely on people to not use march that way.
This can be fixed but I've not done so in this patch.