How to trap unaligned memory access?

Question

I am working on a pet open-source project that implements some stream cipher algorithms and I am having trouble with a bug triggered only when I run it on an ARM processor. I have even tried running the ARM binary in x86 under qemu, but the bug isn't triggered there.

The specifics mechanisms of the bug remains elusive, but my best shot is to believe that it is caused by unaligned memory access attempt made in my program, that is fulfilled by qemu, but silently ignored by the real ARM processor in my development board.

So, since the problem is showing to be very hard to diagnose, I would like to know if there is any tool that I could use to trap unaligned memory access made by my running program, so that I can see exactly where the problem happens.

I could also use some way of enabling, on my ARM development board, some signal (SIGBUS, maybe?) to be issued if the process violates memory alignment restrictions, like we get SIGSEGV when accessing unmapped memory address. It is running Linux 2.6.32.

Answer 1

Linux can do the fixup for you or warn about the access.

You can enable the behavior in /proc/cpu/alignment, see http://www.mjmwired.net/kernel/Documentation/arm/mem_alignment for an explanation of the different values.

0 - Do nothing (default behavior)
1 - Warning in kernel-log with PC and Memory-Address printed.
2 - Fixup error
3 - Warn and Fixup
4 - Send a SIGBUS to the process
5 - Send SIGBUS and output Warning

Answer 2

ARM Linux maintains a list of alignment handler exceptions,

$ cat /proc/cpu/alignment 
User:           0
System:         0
Skipped:        0
Half:           0
Word:           0
DWord:          0
Multi:          0
User faults:    0 (ignored)

It is only active with procfs, but it is hard to imagine a system without procfs. The specific code handling this is in alignment.c. You can use echo 3 > /proc/cpu/alignment to have Linux fixup the instruction and provide some dmesg output. Generally, handling un-aligned accesses through emulation is very in-efficient. It is better to correct the code. The signal option with a debugger attached should give some clue as to the source of the exception.

Read the manual. ;-)