1*4882a593Smuzhiyun================ 2*4882a593SmuzhiyunMemory alignment 3*4882a593Smuzhiyun================ 4*4882a593Smuzhiyun 5*4882a593SmuzhiyunToo many problems popped up because of unnoticed misaligned memory access in 6*4882a593Smuzhiyunkernel code lately. Therefore the alignment fixup is now unconditionally 7*4882a593Smuzhiyunconfigured in for SA11x0 based targets. According to Alan Cox, this is a 8*4882a593Smuzhiyunbad idea to configure it out, but Russell King has some good reasons for 9*4882a593Smuzhiyundoing so on some f***ed up ARM architectures like the EBSA110. However 10*4882a593Smuzhiyunthis is not the case on many design I'm aware of, like all SA11x0 based 11*4882a593Smuzhiyunones. 12*4882a593Smuzhiyun 13*4882a593SmuzhiyunOf course this is a bad idea to rely on the alignment trap to perform 14*4882a593Smuzhiyununaligned memory access in general. If those access are predictable, you 15*4882a593Smuzhiyunare better to use the macros provided by include/asm/unaligned.h. The 16*4882a593Smuzhiyunalignment trap can fixup misaligned access for the exception cases, but at 17*4882a593Smuzhiyuna high performance cost. It better be rare. 18*4882a593Smuzhiyun 19*4882a593SmuzhiyunNow for user space applications, it is possible to configure the alignment 20*4882a593Smuzhiyuntrap to SIGBUS any code performing unaligned access (good for debugging bad 21*4882a593Smuzhiyuncode), or even fixup the access by software like for kernel code. The later 22*4882a593Smuzhiyunmode isn't recommended for performance reasons (just think about the 23*4882a593Smuzhiyunfloating point emulation that works about the same way). Fix your code 24*4882a593Smuzhiyuninstead! 25*4882a593Smuzhiyun 26*4882a593SmuzhiyunPlease note that randomly changing the behaviour without good thought is 27*4882a593Smuzhiyunreal bad - it changes the behaviour of all unaligned instructions in user 28*4882a593Smuzhiyunspace, and might cause programs to fail unexpectedly. 29*4882a593Smuzhiyun 30*4882a593SmuzhiyunTo change the alignment trap behavior, simply echo a number into 31*4882a593Smuzhiyun/proc/cpu/alignment. The number is made up from various bits: 32*4882a593Smuzhiyun 33*4882a593Smuzhiyun=== ======================================================== 34*4882a593Smuzhiyunbit behavior when set 35*4882a593Smuzhiyun=== ======================================================== 36*4882a593Smuzhiyun0 A user process performing an unaligned memory access 37*4882a593Smuzhiyun will cause the kernel to print a message indicating 38*4882a593Smuzhiyun process name, pid, pc, instruction, address, and the 39*4882a593Smuzhiyun fault code. 40*4882a593Smuzhiyun 41*4882a593Smuzhiyun1 The kernel will attempt to fix up the user process 42*4882a593Smuzhiyun performing the unaligned access. This is of course 43*4882a593Smuzhiyun slow (think about the floating point emulator) and 44*4882a593Smuzhiyun not recommended for production use. 45*4882a593Smuzhiyun 46*4882a593Smuzhiyun2 The kernel will send a SIGBUS signal to the user process 47*4882a593Smuzhiyun performing the unaligned access. 48*4882a593Smuzhiyun=== ======================================================== 49*4882a593Smuzhiyun 50*4882a593SmuzhiyunNote that not all combinations are supported - only values 0 through 5. 51*4882a593Smuzhiyun(6 and 7 don't make sense). 52*4882a593Smuzhiyun 53*4882a593SmuzhiyunFor example, the following will turn on the warnings, but without 54*4882a593Smuzhiyunfixing up or sending SIGBUS signals:: 55*4882a593Smuzhiyun 56*4882a593Smuzhiyun echo 1 > /proc/cpu/alignment 57*4882a593Smuzhiyun 58*4882a593SmuzhiyunYou can also read the content of the same file to get statistical 59*4882a593Smuzhiyuninformation on unaligned access occurrences plus the current mode of 60*4882a593Smuzhiyunoperation for user space code. 61*4882a593Smuzhiyun 62*4882a593Smuzhiyun 63*4882a593SmuzhiyunNicolas Pitre, Mar 13, 2001. Modified Russell King, Nov 30, 2001. 64