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 <[email protected]>
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 <[email protected]>
Signed-off-by: Russell King <[email protected]>
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
