]>
Commit | Line | Data |
---|---|---|
dc7a12bd MCC |
1 | ================ |
2 | Memory alignment | |
3 | ================ | |
4 | ||
462e5a52 | 5 | Too many problems popped up because of unnoticed misaligned memory access in |
1da177e4 LT |
6 | kernel code lately. Therefore the alignment fixup is now unconditionally |
7 | configured in for SA11x0 based targets. According to Alan Cox, this is a | |
8 | bad idea to configure it out, but Russell King has some good reasons for | |
9 | doing so on some f***ed up ARM architectures like the EBSA110. However | |
10 | this is not the case on many design I'm aware of, like all SA11x0 based | |
11 | ones. | |
12 | ||
13 | Of course this is a bad idea to rely on the alignment trap to perform | |
14 | unaligned memory access in general. If those access are predictable, you | |
15 | are better to use the macros provided by include/asm/unaligned.h. The | |
16 | alignment trap can fixup misaligned access for the exception cases, but at | |
17 | a high performance cost. It better be rare. | |
18 | ||
19 | Now for user space applications, it is possible to configure the alignment | |
20 | trap to SIGBUS any code performing unaligned access (good for debugging bad | |
21 | code), or even fixup the access by software like for kernel code. The later | |
22 | mode isn't recommended for performance reasons (just think about the | |
23 | floating point emulation that works about the same way). Fix your code | |
24 | instead! | |
25 | ||
26 | Please note that randomly changing the behaviour without good thought is | |
27 | real bad - it changes the behaviour of all unaligned instructions in user | |
28 | space, and might cause programs to fail unexpectedly. | |
29 | ||
30 | To change the alignment trap behavior, simply echo a number into | |
1ada1441 | 31 | /proc/cpu/alignment. The number is made up from various bits: |
1da177e4 | 32 | |
dc7a12bd | 33 | === ======================================================== |
1da177e4 | 34 | bit behavior when set |
dc7a12bd | 35 | === ======================================================== |
1da177e4 LT |
36 | 0 A user process performing an unaligned memory access |
37 | will cause the kernel to print a message indicating | |
38 | process name, pid, pc, instruction, address, and the | |
39 | fault code. | |
40 | ||
41 | 1 The kernel will attempt to fix up the user process | |
42 | performing the unaligned access. This is of course | |
43 | slow (think about the floating point emulator) and | |
44 | not recommended for production use. | |
45 | ||
46 | 2 The kernel will send a SIGBUS signal to the user process | |
47 | performing the unaligned access. | |
dc7a12bd | 48 | === ======================================================== |
1da177e4 LT |
49 | |
50 | Note that not all combinations are supported - only values 0 through 5. | |
51 | (6 and 7 don't make sense). | |
52 | ||
53 | For example, the following will turn on the warnings, but without | |
dc7a12bd | 54 | fixing up or sending SIGBUS signals:: |
1da177e4 | 55 | |
7c2a3e94 | 56 | echo 1 > /proc/cpu/alignment |
1da177e4 LT |
57 | |
58 | You can also read the content of the same file to get statistical | |
59 | information on unaligned access occurrences plus the current mode of | |
60 | operation for user space code. | |
61 | ||
62 | ||
63 | Nicolas Pitre, Mar 13, 2001. Modified Russell King, Nov 30, 2001. |