Re: [PATCH 1/3] ArmPkg/ArmSoftFloatLib: disable LTO build for GCC

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 7 August 2016 at 11:28, Michael Zimmermann <sigmaepsilon92@gmail.com> wrote:
> Hi,
>
> I researched a little bit on this topic and it seems that you have to add
> fuse-linker-plugin to the build options to enable lto plugins.
>

I think that is no longer needed.

> I did that and unfortunately it had no effect. After running gcc through
> strace I could see that liblto_plugin.so does get loaded from the
> cross-toolchains libexec directory though.
>
> Does that mean that the toolchain I use (GCC5 from releases.linaro.org and
> GCC6 from git.linaro.org) generates lto objects which it can't process with
> the shipped plugin?
>

The LTO works fine except for these particular objects. The reason is
that the compiler backend generates the function calls, so they are
not visible to the LTO routines. For this exact reason, I added
liblto-arm.a and liblto-aarch64.a to the normal GCC5 builds

> btw, if I compile using my hosts native GCC(x64) but for IA32 I get lto
> errors even for MdePkg. It looks like the fno-lto option is a very bad
> workaround and can break any time using specific configurations.
>

It shouldn't be. In a normal environment (i.e., building glibc apps),
things like libgcc and anything that is implemented in assembler is
included in the build as  non-LTO objects. The problems specific to
ARM and AARCH64 are the intrinsics, due to the issue mentioned above.
Perhaps we have some of those for IA32 as well? Which entry points
does the build complain about?

-- 
Ard.