[Olsr-dev] alignment faults on ARM processors

[Henning Rogge]

On 08/13/2012 02:40 PM, Kees-Jan Hermans wrote:
> 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 ;-)

As far as I can tell the MIPS processors have the same problem. But they 
do NOT have the problem you describe.

Yes, we cast an uint8_t pointer into an uint_32... but the address in 
the pointer (for this operation) should be well aligned.

Any chance to get a full stack trace (with gdb) which call-chain is 
producing the unaligned function call?

Henning Rogge

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


-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:(spam-protected) http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6169 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20120813/f23da22f/attachment.bin>