On 11/12/2014 01:20 AM, Simon McVittie wrote: > Control: severity 757037 grave > Control: tags 757037 + patch > > I'm bumping this bug up to grave severity, because it seems it makes > this liblzo2 version entirely useless on a fairly common armel CPU (my armel > has a Marvell Kirkwood armv5tel, as used in the SheevaPlug and its > derivatives) in the default Debian configuration. It also makes liblzo2 > FTBFS on such machines, because the tests fail.
Thanks.
> On Sun, 09 Nov 2014 at 21:26:37 +0100, Marc Kleine-Budde wrote:
>> So from my point of view switching unaligned access
>> off in libzop with -DLZO_CFG_NO_UNALIGNED should be done on at least
>> ARMel. Are there other alignment sensitive platforms in debian?
>
> (Please Cc me, I am not subscribed to this bug. Non-maintainer contributors
> to Debian bugs usually aren't.)
Done
> I think alignment-sensitivity is the common case, and quietly accepting
> unaligned accesses (and giving the correct answer!) as is done on x86 is the
> exceptional case...
Looking at the linux Kernel, there we have the
HAVE_EFFICIENT_UNALIGNED_ACCESS kconfig symbol. When an unaligned access
occurs in the kernel it's always fixed up. So the bad code will run, but
not as fast as it could.
> arch/arm/Kconfig:44: select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 ||
> CPU_V6K || CPU_V7) && MMU
Translated to debian this mean:
armel -> unaligned access will silently fail on <= ARMv5
(unless configured otherwise in /proc/cpu/alignment)
will work if run on => ARMv6, e.g. Raspberry Pi, Beagle Bone
But usually you would use armhf on such a system.
armhf -> ok with unaligned access
> arch/arm64/Kconfig:50: select HAVE_EFFICIENT_UNALIGNED_ACCESS
arm64 -> ok
> arch/powerpc/Kconfig:103: select HAVE_EFFICIENT_UNALIGNED_ACCESS if
> !CPU_LITTLE_ENDIAN
ppc, ppc64 -> ok
ppcel -> not ok
> arch/x86/Kconfig:64: select HAVE_EFFICIENT_UNALIGNED_ACCESS
i386, amd64 -> ok
> According to http://www.ibm.com/developerworks/library/pa-dalign/
> the mips family are alignment-sensitive, and so is powerpc sometimes,
> although it might do automatic fixup.
>
> According to https://bugs.launchpad.net/ubuntu/+source/zmqpp/+bug/1256886
> Ubuntu armhf is alignment-sensitive (presumably Debian armhf is the same?)
The just "starting lzop" testcase works on my ARMv7, current debian
testing, both with armhf and armel root filesystem. /proc/cpu/alignment
shows now Problems with the user space.
> I've also seen references to sparc not liking unaligned accesses.
>
> s390 can do unaligned accesses fine according to
> http://lxr.free-electrons.com/source/include/asm-s390/unaligned.h?v=2.2.26,
> but realistically, who's going to test that? Not me :-)
>
> I think the safest thing would be to use -DLZO_CFG_NO_UNALIGNED
> on all Debian architectures except i386, amd64, and maybe the powerpc
> family if someone can test those. I attach a patch that restricts
> use of unaligned accesses to i386 and amd64 CPUs (any kernel);
> it's easy to extend to whitelist other CPUs where unaligned
> accesses are OK.
>
> liblzo2 does actually try to avoid using unsafe unaligned accesses
> by using a structure
>
> typedef struct lzo_memops_TU2_struct { unsigned char a[2]; }
> lzo_memops_TU2;
>
> and only doing a type-punning assignment similar to[1]
>
> *(lzo_memops_TU2 *) (void *) dest = *(const lzo_memops_TU2 *) (void *)
> src;
Which AFAIK should boil down to some kind of memcpy() with compile time
constant length.
> if that structure has required alignment 1... but it seems (recent?) gcc
> might be optimizing that into a single 2-byte operation which requires
> alignment. This might be a gcc bug, but then, I suspect this might be
> a violation of strict aliasing (hence undefined behaviour) if you get all
> language-lawyer about it. Pessimistically assuming that we have to access
> byte-by-byte on miscellaneous architectures seems both quicker and safer
> than working out whether this is the compiler's fault.
>
> tl;dr: the attached patch works, I would suggest using it.
>
> Regards,
> S
>
> [1] Actually it's a little more complicated than that; there are another
> couple of layers of typedef between the source code and the reality
>
regards,
Marc
signature.asc
Description: OpenPGP digital signature
