[Olsr-dev] alignment faults on ARM processors
Mon Aug 13 14:40:06 CEST 2012
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.
> 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
More information about the Olsr-dev