Bug 249775

Created attachment 51188 [details]
valgrind -v output for secondary failure

> With the attached patch (which just enables the stubbed out /*atc*/
> handling of this case)

"atc" stands for "awaiting test case".  It means the handler got
written but no instance of the instruction has so far been seen.

> valgrind proceeds past this point and works at least some of the
> time. However it then intermittently fails (perhaps one run in three) with
> 
> ==18028== Process terminating with default action of signal 4 (SIGILL)
> ==18028==  Illegal opcode at address 0x6285008C
> ==18028==    at 0x40112F4: __sigsetjmp (setjmp.S:59)
> ==18028==    by 0x400B040: _dl_catch_error (dl-error.c:175)
> ==18028==    by 0x4009E66: _dl_map_object_deps (dl-deps.c:249)
> ==18028== Jump to the invalid address stated on the next line
> ==18028==    at 0x3E4: ???
> ==18028==  Address 0x3e4 is not stack'd, malloc'd or (recently) free'd

That's (confusingly) a fault in the JIT generated code, not in the
front end.  An easy way to debug is to rerun with --wait-for-gdb=yes,
which puts V in a minute-ish long spin loop.  In that time, attach gdb
to it from another shell and let it continue.  You might also have to
continue past a few (expected) segfaults.  Eventually you should
get to the SIGILL.

I wonder if this is fallout from mis-handling BX PC, but I can't see
how.  It would be useful to see how the simulator got to this place.
Re-run with --trace-flags=10000000 --trace-notbelow=99999.
Once you see what SB number it's failing on, change the 99999 to that
number (or one or two just below) so you can see what insns the front
end is decoding.

The secondary problem turns out to be unrelated to BX PC. The problematic
instruction is an fstmiad in __sigsetjmp:

        (arm) 0x40112F4:  fstmiad r12!, {d8-d15}

              ------ IMark(0x40112F4, 4) ------
              t0 = GET:I32(48)
              t1 = Add32(t0,0x40:I32)
              t2 = t0
              STle(Add32(t2,0x0:I32)) = GET:F64(184)
              STle(Add32(t2,0x8:I32)) = GET:F64(192)
              STle(Add32(t2,0x10:I32)) = GET:F64(200)
              STle(Add32(t2,0x18:I32)) = GET:F64(208)
              STle(Add32(t2,0x20:I32)) = GET:F64(216)
              STle(Add32(t2,0x28:I32)) = GET:F64(224)
              STle(Add32(t2,0x30:I32)) = GET:F64(232)
              STle(Add32(t2,0x38:I32)) = GET:F64(240)
              PUT(48) = t1

That gets translated into a code sequence which includes
  vld1.32 {d8} [r9]
  8F 87 29 F4 

VLD1 is a Neon instruction, and this system doesn't have Neon, only VFP, so we SIGILL when we try to execute it.

Valgrind is incorrectly deciding that we do have neon; on startup it says "Arch and hwcaps: ARM, ARMv7-vfp-neon".

I'm not sure why machine_get_hwcaps() is diagnosing the system as having Neon: if I single step through it in gdb then we get a SIGILL on the 'vorr q2,q2,q2' diagnostic insn it is using, and the NEON bit is not set in hwcaps. However if I let gdb run through the function rather than stepping then we do not get a SIGILL, and the NEON bit is set...

(The runs where valgrind works also diagnose the machine as having neon, so it's not that the diagnosis is giving variable results; it's consistently wrong when not being singlestepped, it's just that the wrong diagnosis doesn't always cause a crash later.)

> I'm not sure why machine_get_hwcaps() is diagnosing the system as having Neon

"Does this neon instruction execute?" is apparently not a valid way to make this check -- the kernel may have had support compiled out or disabled because of hardware issues. I'm told you need to check for HWCAP_NEON in /proc/self/auxv.

I hacked machine_get_hwcaps() to force it to say 'no neon', and the intermittent failures have gone away.

(In reply to comment #4)
> "Does this neon instruction execute?" is apparently not a valid way to make
> this check

Yes, I'd wondered exactly that.  Thanks for chasing it.  Does that go
only for detecting NEON support, or will we have to check all the
features using /proc/self/aux ?

> I hacked machine_get_hwcaps() to force it to say 'no neon', and the
> intermittent failures have gone away.

Good.  So at least the backend instruction selection logic is working
correctly w.r.t. hw capabilities.

(In reply to comment #5)
> Does that go
> only for detecting NEON support, or will we have to check all the
> features using /proc/self/aux ?

You need to do that for at least Neon and VFP support. I don't think it's as critical for "are we v5/v6/v7?" but I imagine that if you're reading /proc/self/auxv for AT_HWCAP it's as simple to look at AT_PLATFORM to determine v5/v6/v7 as it is to do it by testing for faulting instructions.

> patch which enables support for BX PC

Committed as r2027.  Thanks.

Changed the title to reflect the more serious bug.

Fixed, r11347/r2032.

r11347 only checks the auxv for Neon; I think you also need to do this for VFP.

Reopening.  (What's the right way to reopen a bug?)  But would prefer to
see a real failure as a result of not correctly detecting VFP before
fixing.

I think for a test case you'd could try building a kernel with no VFP support and running it on an A8 or similar. But I suspect that it's basically that at the moment you're relying on something that happens to work but which isn't guaranteed to do so. (We just don't happen to currently have any hardware with broken VFP the way we do Neon.)

Sorry, I didn't mean to change the status fields there.