Bug 67871 - LTO falis for ARM big-endian
Summary: LTO falis for ARM big-endian
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 6.0
: P3 major
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: lto
Depends on:
Reported: 2015-10-06 19:18 UTC by Jonathan Roelofs
Modified: 2015-10-21 21:22 UTC (History)
1 user (show)

See Also:
Target: arm-eabi
Known to work:
Known to fail:
Last reconfirmed: 2015-10-15 00:00:00

fix implementation (gcc) (464 bytes, patch)
2015-10-21 20:29 UTC, Jonathan Roelofs
Details | Diff
fix implementation (binutils) (400 bytes, patch)
2015-10-21 20:30 UTC, Jonathan Roelofs
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Roelofs 2015-10-06 19:18:21 UTC
$ 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
Comment 1 Richard Biener 2015-10-07 08:03:24 UTC
I suppose -mbig-endian doesn't get transfered to lto1 properly.
Comment 2 Ramana Radhakrishnan 2015-10-15 19:42:23 UTC
Do you have big endian multilibs suitably built ? How did you configure your toolchain ?

I am unable to replicate this issue.
Comment 3 Jonathan Roelofs 2015-10-15 20:42:32 UTC
(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.
Comment 4 Jonathan Roelofs 2015-10-15 20:46:08 UTC
Comment 5 Jonathan Roelofs 2015-10-16 20:19:34 UTC
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:

commit 5ae0078cd2b6b69e6119864e20987c8724916b29
Author: H.J. Lu <hjl.tools@gmail.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.
Comment 6 Jonathan Roelofs 2015-10-16 20:39:17 UTC
I've filed the corresponding binutils report here: https://sourceware.org/bugzilla/show_bug.cgi?id=19145
Comment 7 H.J. Lu 2015-10-18 15:47:20 UTC
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
to linker.
Comment 8 Jonathan Roelofs 2015-10-21 20:29:53 UTC
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.
Comment 9 Jonathan Roelofs 2015-10-21 20:30:28 UTC
Created attachment 36558 [details]
fix implementation (binutils)
Comment 10 Jonathan Roelofs 2015-10-21 21:22:07 UTC