[PATCH][ARM] FAIL: gcc.target/arm/pr58041.c scan-assembler ldrb

[Maciej W. Rozycki]

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 <kirill@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 <kirill@shutemov.name>
    Signed-off-by: Russell King <rmk+kernel@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