Searched hist:"8420 a14c2cfb3f3d258b70e05dd3a9a388fdf1f5" (Results 1 – 1 of 1) sorted by relevance
| /optee_os/core/arch/arm/ |
| H A D | arm.mk | 8420a14c2cfb3f3d258b70e05dd3a9a388fdf1f5 Tue Jun 02 12:09:01 UTC 2020 Jerome Forissier <jerome@forissier.org> Disable CFG_SCTLR_ALIGNMENT_CHECK (SCTLR.A) by default
With ARM CPUs, unaligned accesses are forbidden in a number of cases
such as when the MMU is disabled, or when device memory is concerned,
or with atomic instructions. However in the general case [1] and for
all modern ARMv7-A and ARMv8-A processors, they do not really matter.
Compilers such as GCC and Clang will generate unaligned accesses by
default; a specific flag (-mstrict-align or --mno-unaligned-access) has
to be supplied to prevent such code from being output.
[1] Roughly speaking: LDR/STR instructions operating on normal cached
memory.
The SCTLR.A bit ("Alignment check enable") defines whether the CPU
should allow these unaligned accesses (when set to 0) or should trap
(when set to 1). Having SCTLR.A enabled by default can be annoying for
a couple of reasons that we have met in practice:
1. TAs linked against a third-party library. Since strict alignment
is not a compiler default, it is likely that a third party library does
not enforce it. With SCTLR.A == 1, such a library would have to be
recompiled in order to be used by a TA. Recompiling may or may not be
an easy task. Concrete example: libgcc_eh.a (the C++ exception handling
support library, part of the arm-linux-gnueabihf and aarch64-linux-gnu
toolchains).
2. Compiler bug. For example, Clang 9.0.1 and 10.0.0 may erroneously
replace memcmp() calls with inline code performing unaligned accesses
[2].
All things being considered, it seems preferable for SCTLR.A to be
cleared by default, i.e., CFG_SCTLR_ALIGNMENT_CHECK=n, which is what
this commit does. The configuration variable is kept just in case.
Note that the Linux kernel and the KVM hypervisor do not set SCTLR.A or
HSCTLR.A either.
Note regarding code running before the MMU is enabled: when SCTLR.M is
clear all accesses are treated as with DEVICE attribute and hence
SCTLR.A has no effect. It will trap unaligned accesses regardless. So
this patch will have no side effect.
Link: [2] http://lists.llvm.org/pipermail/llvm-dev/2020-June/141985.html
Signed-off-by: Jerome Forissier <jerome@forissier.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
|