$ touch empty.c
$ arm-none-eabi-gcc -mbig-endian -flto empty.c
/tmp/ccUtMyOv.o: file not recognized: File format is ambiguous
/tmp/ccUtMyOv.o: matching formats: elf32-bigarm elf32-big
collect2: error: ld returned 1 exit status
I suppose -mbig-endian doesn't get transfered to lto1 properly.
Do you have big endian multilibs suitably built ? How did you configure your toolchain ?
I am unable to replicate this issue.
(In reply to Ramana Radhakrishnan from comment #2)
> Do you have big endian multilibs suitably built ?
Yes, both the big-endian and little-endian multilibs seem to work, and have reasonable results in the testsuite... except for the big-endian + lto tests, that is, which all fail with the same symptoms as my reduced testcase.
> How did you configure your toolchain ?
gcc was configured with:
/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/src/gcc-mainline/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-eabi --enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --disable-shared --enable-lto --with-newlib --disable-nls --prefix=/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/install --with-headers=yes --with-sysroot=/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/install/arm-none-eabi --with-gmp=/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/obj/pkg-mainline-0-arm-none-eabi/fsf-mainline-0-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr --with-mpfr=/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/obj/pkg-mainline-0-arm-none-eabi/fsf-mainline-0-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr --with-mpc=/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/obj/pkg-mainline-0-arm-none-eabi/fsf-mainline-0-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr --with-isl=/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/obj/pkg-mainline-0-arm-none-eabi/fsf-mainline-0-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr --disable-libgomp --disable-libitm --disable-libatomic --disable-libssp --disable-libcc1 --enable-poison-system-directories --with-python-dir=arm-none-eabi/share/gdb/python --with-build-time-tools=/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/install/arm-none-eabi/bin --with-build-time-tools=/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/install/arm-none-eabi/bin SED=sed
ginutils was configured with:
/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/obj/binutils-src-mainline-0-arm-none-eabi-i686-pc-linux-gnu/configure --prefix=/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/install --build=i686-pc-linux-gnu --target=arm-none-eabi --host=i686-pc-linux-gnu --disable-gdb --disable-libdecnumber --disable-readline --disable-sim --disable-nls --with-sysroot=/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/install/arm-none-eabi --enable-poison-system-directories --enable-plugins
both pulled from trunk.
> I am unable to replicate this issue.
After further inspection, this looks like a binutils bug.
Holding the gcc revision constant, I git-bisected, and ended up with this commit as the culprit:
Author: H.J. Lu <email@example.com>
Date: Wed Feb 11 05:01:03 2015 -0800
Merge linker plugin handling into BFD plugin support
Linker plugin_maybe_claim is the interface of linker plugin support.
This patch extracts linker plugin_maybe_claim into plugin_object_p and
makes it available to BFD via a new function:
void register_ld_plugin_object_p (const bfd_target *(*) (bfd *));
bfd_plugin_object_p calls plugin_object_p registered by linker first. It
adds an enum bfd_plugin_format field and a pointer to plugin dummy BFD so
that plugin_object_p stores plugin dummy BFD to allow plugin_maybe_claim
to retrieve it later.
I've filed the corresponding binutils report here: https://sourceware.org/bugzilla/show_bug.cgi?id=19145
arm-none-eabi GCC only supports little-endian, not big-endian and
armeb-none-eabi GCC only supports big-endian, not little-endian.
To make them support both, you need to pass the right -m option
Created attachment 36557 [details]
fix implementation (gcc)
I've implemented the fix you described in the binutils thread, and it does in fact clear up the issue I was originally seeing.
I'd like to see this committed upstream if possible.
Created attachment 36558 [details]
fix implementation (binutils)