Build breakage on ARMv6 devices with v0.11 branch

[adammw]

I've just been pinged on Twitter that the v0.11.9 build here throws an illegal instruction on ARMv6 devices (basically the Raspberry Pi, I haven't tested any other devices). Seems to do the same on all of the "offical" builds past v0.11.8.

Running node --v8-options presents:

target arm v6 vfp2 hard
ARMv7=1 VFP3=0 VFP32DREGS=0 NEON=0 SUDIV=0 UNALIGNED_ACCESSES=1 MOVW_MOVT_IMMEDIATE_LOADS=0 USE_EABI_HARDFLOAT=1

On v0.11.7:

target arm v6 vfp2 hard
ARMv7=0 VFP3=0 VFP32DREGS=0 NEON=0 SUDIV=0 UNALIGNED_ACCESSES=0 MOVW_MOVT_IMMEDIATE_LOADS=0 USE_EABI_HARDFLOAT=1

Obviously, an armv6 shouldn't be setting the ARMv7 flag, and that's causing illegal instructions to be generated.

I've been able to bisect it to something being changed between v0.11.7 and v0.11.8, but I haven't yet found the commit or change that needs reverting.

[adammw]

My guess is a53c763, but I could very well be wrong.

[fivdi]

Looks like it's this.

In order to determine the ARM architecture on the Pi, V8 scans the Processor field in /proc/cpuinfo for "(v6l)". If it finds "(v6l)" it assumes ARMv6 which is correct, if it doesn't, it assumes ARMv7 which is incorrect.

Everything works correctly on older versions of Raspbian with the following /proc/cpuinfo:

Processor   : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS    : 697.95
Features    : swp half thumb fastmult vfp edsp java tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part    : 0xb76
CPU revision    : 7

Hardware    : BCM2708
Revision    : 0002
Serial      : 000000008a51a472

However, on newer versions of Raspbian "(v6l)" has been moved to the model name field, V8 doesn't find it, and assumes that the Pi has an ARMv7 processor:

processor   : 0
model name  : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS    : 2.00
Features    : swp half thumb fastmult vfp edsp java tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part    : 0xb76
CPU revision    : 7

Hardware    : BCM2708
Revision    : 0002
Serial      : 000000008a51a472

All the Raspbian builds should work on older versions of Raspbian, but v0.11.8 and higher won't run on new versions of Raspbian.

[senditu]

Has there been any movement on this? I tried compiling 11.13 on the pi overnight, and I'm still getting illegal hardware instructions upon execution. Is there a variable I can set somewhere so that I can get it to properly compile, at least? I'm building on Arch ARM...

Thanks

There are a lot of missing ARM pi builds missing. The newest 0.10x version I found is
http://nodejs.org/dist/v0.10.26/

[needforspeed]

@senditu @Lope The last one works for arm5 was v0.10.29.

[indutny]

Should be fixed by #8230 after merge in v0.11

[peerchemist]

It is still broken, just tried with 0.11.14 on raspberry pi (armv6h)

node --v8-options

target arm v6 vfp2 hard
ARMv7=1 VFP3=0 VFP32DREGS=0 NEON=0 SUDIV=0 UNALIGNED_ACCESSES=1 MOVW_MOVT_IMMEDIATE_LOADS=0 USE_EABI_HARDFLOAT=1

It still detects armv6h as armv7.

[dionoid]

Any updates on this issue? Still unable to run the latest 0.11 version on my Raspberry Pi.

[sxa]

Last time I built it on ARM the fix in #8589 allowed it to work.

[dionoid]

Hi sxa555, sorry, I tried a version of the source before that fix. Will try again.

[wilson0x4d]

Cross-posted from another thread:

I also had previously edited configure to force the use of "vfpv2" instead of "vfpv3" by changing:

o['variables']['arm_fpu'] = 'vfpv3' # V8 3.18 no longer supports VFP2.
to
o['variables']['arm_fpu'] = 'vfpv2' # V8 3.18 no longer supports VFP2.

In addition to the armv6 change to cpu.cc.

Since "vfpv2" isn't considered supported in "v8" I have not generated a patch (I'm really not sure what the correct action is wrt the configure script tbh.) My limited understanding is that 'vfp' are floating point extensions, and my assumption here is that by specifying vfpv2 the node build is omitting said extensions (as the VFP3=0 from --v8-options suggests.) Thus, someone will probably want to generate an appropriate patch to configure, or perhaps give me some insight into what scenarios it is acceptable (or unacceptable) to opt out of VFPv3.