On 17 August 2015 at 11:47, Leif Lindholm leif.lindholm@linaro.org wrote:
On Mon, Aug 17, 2015 at 11:19:59AM +0200, Ard Biesheuvel wrote:
On 17 August 2015 at 11:12, Leif Lindholm leif.lindholm@linaro.org wrote:
Hi Ard,
On Mon, Aug 17, 2015 at 10:53:59AM +0200, Ard Biesheuvel wrote:
FYI I am adding the below patch to my GCC consolidation series.
Whilst I agree with the spirit of this patch, I have some concerns (basically I think it's too soon).
-------------8<--------------- In GCC 4.7, a feature was added to the ARM backend that allows unaligned loads and stores to be emitted. Since it is enabled by default on ARMv6 and later CPUs, and since such code is not suitable in our case (i.e., bare metal code), we must disable it by passing the -mno-unaligned-access option if we are using GCC 4.7 or later.
However, this particular feature and its enabling by default have been backported to version 4.6 by Linaro. Since the Linaro toolchains are widely used for ARM development, and also shipped by distros such as Ubuntu, we should disable the feature on version 4.6 as well.
I don't think it's that simple. I know some of the Ubuntu ones did _not_ support this flag (I'm thinking it was 12.04 I was using for GRUB development, and hitting this one.) And that's an LTS which will be supported until 2017.
And I've also seen people using codesourcery for edk2 development.
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.
As a workaround, we could build the C code for armv5, I suppose, because that will implicitly disable the feature if it is supported, and only generate suboptimal code otherwise. Or enable unaligned accesses in the MMU?
Don't think we can guarantee only aligned accesses before MMU is enabled with any level of certainty. And even if we could it would be very fragile, which is a bad combination with the lower level of testing 4.6 is likely to see.
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.
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.
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)