On Tue, 27 May 2014, Richard Earnshaw wrote: > > Afterwards it is: > > > > .L14: > > vldr d16, [r3, #-16] > > vldr d17, [r3, #-8] > > add r3, r3, #16 > > cmp r3, r1 > > vst1.64 {d16-d17}, [r2:64]! > > bne .L14 > > > > and the second VLDR instruction traps with SIGILL (the value in R3 is > > 0x10b29, odd as you'd expect, pointing into `ib'). I don't know why and > > especially why only the second of the two (regrettably I've been unable to > > track down an instruction reference that'd be detailed enough to specify > > what exceptions VLDR can produce and under what conditions). > > > > SIGILL means "undefined instruction". It does not mean misaligned > address (unless the kernel is messed up) -- that would be SIGBUS.
The kernel has some code to fix up user unaligned accesses that have caused a trap but VLDR is not among the instructions handled AFAICT. This may well be the cause of the messup, including the difference seen when single-stepping. And sending the wrong signal in this case would be a kernel bug too. I went ahead and checked the kernel log and it's indeed the case: [28632.927062] Alignment trap: not handling instruction ed530b04 at [<000087e0>] [28632.934692] Unhandled fault: alignment exception (0x011) at 0x00010b19 [28634.778594] Alignment trap: not handling instruction ed531b02 at [<000087e4>] [28634.786163] Unhandled fault: alignment exception (0x001) at 0x00010b21 which correspond to (from `objdump -d'): 87e0: ed530b04 vldr d16, [r3, #-16] 87e4: ed531b02 vldr d17, [r3, #-8] And it may well be that the kernel this board runs predates this: commit 3dc91aff9c3ef54b15cdaf32f61f973489fe69eb Author: Kirill A. Shutemov <kir...@shutemov.name> Date: Thu Jul 22 13:16:49 2010 +0100 ARM: 6252/1: Use SIGBUS for unaligned access instead of SIGILL POSIX specify to use signal SIGBUS with code BUS_ADRALN for invalid address alignment. Signed-off-by: Kirill A. Shutemov <kir...@shutemov.name> Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk> In any case such code is not supposed to have been produced in the first place, so don't let any kernel bugs or shortcomings distract us. Maciej