On Mon, Aug 17, 2015 at 12:18:13PM +0200, Ard Biesheuvel wrote:
The problem is that when you /do/ use the Linaro 4.6 toolchain, we won't pass the -mno-unaligned-access flag (since upstream does not support it) and it will go and emit unaligned memory accesses which cause the resulting firmware to blow up.
Sure, but that's the status quo. We won't break anyone's working infrastructure by keeping it that way.
I think that's a pretty unambitious definition of 'working' if it is producing builds that may be broken in unexpected ways.
Dropping GCC46 and telling people to use GCC47 instead will break setups that are genuinely working today. Gcc4.6 without the Linaro patches does not generate unaligned accesses. A switch to supporting only GCC47 will explicitly break the setups that are the only ones known to be generating correct code today.
Unfortunately, since the upstream version does not support the feature, it also does not understand the -mno-unaligned-access option.
Considering the above, and the fact that the oldest supported toolchain for AARCH64 is 4.7 as well, let's just drop support for 4.6 altogether.
My request would be to hold back on this one for a while. Certainly give it a few months between dropping pre-v7 support and dropping gcc4.6.
IMO we have to do something to address the current situation. Got any other ideas besides -march=armv5t ?
Do we?
As Linaro UEFI maintainers, I think we should do everything we can to prevent people from using *our* toolchain to produce firmware images that we know may be broken.
As ARM architecture UEFI maintainers, I think it's important that we do not get into playing favourites. The best solution I see is actively discouraging people from using Linaro toolchains prior to gcc4.7 for edk2 development (see below).
Surely, if someone is having problems deploying gcc4.6 because the Linaro version enables unaligned accesse where it shouldn't, they should switch to a pure upstream compiler or step to a later toolchain?
(Yes, I realise this includes our very own matrix build.)
That presumes awareness of the fact. The issue here is that the brokenness of the resulting firmware images has not manifested itself yet.
Indeed.
There is a __ARM_FEATURE_UNALIGNED builtin define that we can test for in some header that all platforms include, and #error if it is set. Other than that, I think dropping 4.6 is the only reasonable course of action. (Setting arch=armv5t conflicts badly with the mthumb and cpu=cortex-a15 options that are passed in various places)
I would be entirely happy with a test in a critical header for __ARM_FEATURE_UNALIGNED with GCC46 and bailing on it. Unlike dropping GCC46, this will also raise a flag to current users of unsafe build setups that something is wrong.
Then if they come asking why their build breaks, we tell them that they need to use the GCC47 profile.
/ Leif