On 12/11/14 10:51, Marc Kleine-Budde wrote:
> On 11/12/2014 01:20 AM, Simon McVittie wrote:
> 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
If the lzo2 maintainer would prefer, I'd be happy to adapt my patch to
allow unaligned accesses on additional architectures, or to swap the
assumption around so that it only forbids unaligned architectures on
specific architectures (which should include armel, and I don't
personally care about any others, but the mips* porters might).
If we need to differentiate between armel and armhf then it will be
necessary to use DEB_HOST_ARCH instead of DEB_HOST_ARCH_CPU (both
armel and armhf have "arm" as their DEB_HOST_ARCH_CPU), with something
like:
# whitelist approach
ifeq ($(filter amd64 %-amd64 i386 %-i386 armhf,$(DEB_HOST_ARCH)),)
# neither x86 family nor armhf: unaligned accesses are not good
endif
or
# blacklist approach
ifeq ($(filter-out armel mips%,$(DEB_HOST_ARCH)),)
# armel or mips-family: unaligned accesses are not good
endif
However, I will not be able to test on a baseline specimen of each
Debian architecture, because Debian porterboxes are not guaranteed to
match the baseline for the architecture: armel porterboxes are likely
to be better than armv5 in practice, i386 porterboxes are definitely
better than i586, and so on.
The only non-porterbox machines that I can personally test are an
armv5tel and a modern x86-64.
>> 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.
That's what I'd expect too, but judging by the failure we're seeing,
it looks as though the compiler might be producing a single "load
16-bit" instruction, which is considerably cheaper but assumes alignment.
S
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
