1285190 - ARM simulator's alignment faulting is basically broken

Status: NEW

(Core :: JavaScript Engine: JIT, enhancement, P3)

Description

[Lars T Hansen [:lth]]

The ARM simulator occasionally looks at HasAlignmentFault() to determine whether it should fault an unaligned load or not.  It does not do so systematically, nor does it do it correctly, nor does it handle stores.

For example, the simulator allows unaligned Exclusive accesses, which are not allowed by the ARM ARM.  For another example, the lenient behavior is implemented by readW(), but readW() is used as a subroutine by instructions that do not allow faulting.

The pertinent section of the ARMv7 ARM is 3.2.  To summarize, if SCTRL.A is 0 then the following non-byte-sized memory access instructions perform an unaligned access.  All other instructions must fault.  If SCTRL.A is 1 then the following instructions must also fault.

LDRH, LDRHT, LDRSH, LDRSHT, STRH, STRHT, TBH
LDR, LDRT, STR, STRT
PUSH, encodings T3 and A2 only
POP, encodings T3 and A2 only
VLD1, VLD2, VLD3, VLD4, VST1, VST2, VST3, VST4, all with standard alignment

I don't think we're currently trusting the simulator to get this right anyway, but we should fix it.

Comment 1

[Benjamin Bouvier [:bbouvier] (inactive)]

Yes indeed; I've started adding a few calls to HasAlignmentFault() in several other read*/write* functions, but this might not be enough. And as you say, I have not checked the callers, to these functions might be used in other contexts that wouldn't fault on real-world devices.

For what it's worth, it's never tested: by default, the bit tested by HasAlignmentFault() is never set during testing. The only way to test for alignment faults is to set this env variable by hand: ARM_HWCAP=align.

The simulator doesn't help identifying which instructions it executes, because it mentions instructions of type 1, 2, etc. Maybe they have a mapping in ARM's naming conventions? But out of the blue, they seem like obscure randomly picked names.

I really wish we could improve our support of alignment faults. I've looked at a few RegExp crashes yesterday, and quite a number of them happening on ARM are SIGBUS...

Comment 2

[Lars T Hansen [:lth]]

There's a patch pending on bug 1277011 that addresses some of this (and sets up a system that could be used to address more cases, eg, on halfword accesses).

:bbouvier, the type 1, type 2 etc refers to bits 25..27 of the ARM instruction word.  If you look eg at LDR you'll see those bits are 011, ie, type 3.  It's a mess to try to go from simulator code back to the appropriate instruction definition...

Comment 3

[Lars T Hansen [:lth]]

Not actually working on this at the moment.  Also, the situation is quite a bit better than it used to be.