Alignment checking on ARM

[Adam Lackorzynski]

Hi,

this setting is only relevant for bootstrap. The kernel has its own
(configurable) alignment checking setting.
For bootstrap it is merely a historic precaution thing and with today's
compilers / CPUs it should be removed, at least for v6+.


Adam

On Mon Nov 25, 2019 at 15:03:37 +0000, Al Grant wrote:
> I'm building L4 on ARM using GCC 7.4.0 on Cortex-A15. ARCH-arm/head.cc enables
> alignment checking (sets SCTLR.A=1), but we then see an alignment check fault in
> init_kip_f.cc. With the default compiler options, the GCC cross tools will assume
> alignment checking is _not_ enabled and will generate code that may use unaligned
> access.
> 
> We can override this by compiling with -mno-unaligned-access. But it would be
> good to know what is intended. If the intention is to be able to run "mainstream"
> open-source code in userspace, i.e. build code using the standard Linux ABI,
> we ought to allow that, and not enable alignment checks in SCTLR. Some code
> will not be fixed by compiling -mno-unaligned-access (because it casts arbitrary
> unaligned pointers to word-sized types etc.)
> 
> So my question is, what is the intention?
> 
>   (1) fault unaligned access in kernel and userspace
> 
>   (2) fault unaligned access in kernel but allow in userspace
> 
>   (3) allow unaligned access in kernel and userspace
> 
> I'm assuming it can't be (3) as the bootstrap code explicitly enables alignment checking.
> (2) would be a good compromise, it would enable alignment checks which would pick
> up some possible faults in the kernel, but it would improve portability of ordinary
> open-source packages in userspace.
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.