On Fri, Nov 21, 2014 at 12:42:34PM +0000, Simon McVittie wrote:
> A couple of questions for people who know low-level things:
>
> * Of Debian's architectures (official and otherwise), which ones are
> known/defined/designed to be OK with unaligned accesses from
> user-space, and which ones (can be configured to) crash or give wrong
> answers?
>
> * Would it be safer to assume that future architectures are in the
> "unaligned accesses are OK" category, or the "not OK"
> category?
>
> The ones I know for sure are:
>
> - OK: any-i386, any-amd64
> - not OK: armel
>
> I believe powerpc, s390 and arm64 might be in the "OK" category, and
> mips* and sparc in the "not OK" category. I've seen conflicting
> information about which category armhf is in: on #757037, Marc
> Kleine-Budde said that ARMv6 and up guarantee that unaligned access is
> fine, but I've also found Ubuntu bug reports about unaligned access
> failures on armhf.
So, the short answer for the ARM case is that ARMv6 and up guarantee
that the processor can be configured such that_some_ unaligned
accesses are fine (or at least just inefficient). Linux by default
enab this mode - so:
- All <=32-bit load/store operations can be unaligned.
- NEON load-stores can be unaligned (unless an explicit alignment is
specified in the encoding).
But:
- VFP load/stores must be naturally aligned.
- Load-multiple/store-multiple and ldrd/strd do not work with <32-bit
alignment, but can sometimes get fixed up by the kernel
_at_a_substantial_performance_penalty_.
PUSH/POP usually requires 32-bit alignment, but then the ABI requires
64-bit alignment of the stack, so that is less of an issue.
Unaligned load-exclusive/store-exclusive operations are not supported.
No unaligned accesses are permitted to memory regions of Device or
Strongly-ordered type. But some permutation of this will be true for
most architectures, and in user-space this would only affect things
prodding /dev/mem or otherwise mmaping from a device driver.
ARM64 similarly makes it possible to trap unaligned accesses, but if
that is not enabled (which it isn't by Linux), everything apart from
load-exclusive/store-exclusive, load-acquire/store-release and Device
memory accesses will be handled by hardware.
There are additional restrictions with regards to guarantees about the
atomicity of memory accesses, but I won't go into that now since it is
a bit of a special case.
/
Leif
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141121140055.gk22...@bivouac.eciton.net
