[Olsr-dev] alignment faults on ARM processors

[Kees-Jan Hermans]

Basically, it cannot access a piece of 32 byte memory (i.e. following a
pointer-to-int cast) without it being properly aligned (at a four byte
boundary). It also cannot copy a 16 bit piece of memory that 'hangs
over' a boundary. But it *can* memcpy() - it's just expensive. In a
world where ethernet headers are 14 bytes long, that's a major pain, I
can tell you ;-)

On Mon, 2012-08-13 at 13:55 +0200, Henning Rogge wrote:
> On 08/13/2012 10:21 AM, Kees-Jan Hermans wrote:
> > 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.
> 
> Could it be that the Marvell CPU wants to have an alignment of more than 
> 4 bytes?

No, in my experience, it's 4.

KJ

> 
> Henning Rogge
> 
> > 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
> >>
> >
> 
>