[Olsr-dev] alignment faults on ARM processors

[Kees-Jan Hermans]

I've had this problem on Marvell as well (with another application) - I
resorted to create macroes for such casts that are casts on most
platforms, and memcpy()s on ARM.

KJ

On Thu, 2012-07-26 at 09:11 -0500, Peter Bigot wrote:
> I was recently asked to validate OLSRD on a custom embedded platform
> involving an AT91 ARM processor and Linux 2.6.39 under OpenEmbedded
> Classic.  While the 0.5.5 release worked, 0.5.6-r8 and 0.6.3 produced
> a cascade of errors attempting to route to invalid IP addresses.
> 
> A kernel error message indicated unaligned accesses.  I tracked this
> down to several uses of the following idiom in src/lq_packet.h:
> 
>   *var = ntohl(**((const uint32_t **)p));
> 
> where p is a pointer to a pointer to const uint8_t.  It seems that in
> recent Linux kernels CONFIG_ALIGNMENT_TRAP is enabled by default on
> these ARM chips, and the version of Sourcery_G++_Lite required on this
> platform does not support -mno-alignment-traps.  In practice, the
> pointer at this point did not satisfy the alignment requirements of
> the processor, and the kernel did not provide a recovery.
> 
> I worked around this by replacing the assignment with an intermediate
> copy from the unaligned buffer into a 4-byte region in a local union
> with a uint32_t; similarly for the int16_t accesses.  I regret that I
> can't provide the patch (which is both trivial and a hack anyway), but
> thought a heads-up might be helpful for others trying to make OLSRD
> work in a similar environment.
> 
> Peter
>