Created attachment 342514 [details] v8-3.16.14.2-armv7-vfp3.patch The V8 build process generates a VM snapshot of the JavaScript base context, which speeds up V8 initialization at runtime. Unfortunately, in order to support cross-compilation, the build process does not do CPU feature detection and instead relies on command-line flags. Building dev-lang/v8-3.16.14.2 on the Raspberry Pi (ARMv6zk+VFPv2) results in a build failure due to an "Illegal instruction", which occurs because the build assumes an ARMv7+VFPv3 CPU. The attached patch to the ebuild allows V8 to build successfully on the Raspberry Pi.
Matt, thank you for the patch. Could you rebase it for v8-3.17.16.2?
Created attachment 345724 [details, diff] v8-3.17.16.2-armv6.patch (In reply to comment #1) > Matt, thank you for the patch. > > Could you rebase it for v8-3.17.16.2? The method of configuration changed from v8-3.16.14.2 to v8-3.17.16.2. This new patch works on the gyp-based configuration in v8-3.17.16.2. I'm building it on my Raspberry Pi right now. The preprocessor defines look good: '-DENABLE_DEBUGGER_SUPPORT' '-DV8_TARGET_ARCH_ARM' '-DUSE_EABI_HARDFLOAT=1' '-DCAN_USE_VFP2_INSTRUCTIONS' '-DBUILDING_V8_SHARED' '-DV8_SHARED' Contrast those defines with the ones caused by the unpatched ebuild: '-DENABLE_DEBUGGER_SUPPORT' '-DV8_TARGET_ARCH_ARM' '-DCAN_USE_ARMV7_INSTRUCTIONS=1' '-DCAN_USE_VFP2_INSTRUCTIONS' '-DCAN_USE_VFP3_INSTRUCTIONS' '-DUSE_EABI_HARDFLOAT=1' '-DBUILDING_V8_SHARED' '-DV8_SHARED'
(In reply to comment #2) > The method of configuration changed from v8-3.16.14.2 to v8-3.17.16.2. This > new patch works on the gyp-based configuration in v8-3.17.16.2. > > I'm building it on my Raspberry Pi right now. The preprocessor defines look > good. Thank you. Are you sure about "-Darm_fpu=" ? Is making it empty necessary? Same for neon - I'd prefer to have a separate bug for neon support, and focus on the compile issue here. I'd prefer to avoid making these two changes simultaneously since it's harder to debug failures then (determine which change broke the build).
(In reply to comment #3) > Thank you. Are you sure about "-Darm_fpu=" ? Is making it empty necessary? Yes. If you don't define arm_fpu, then build/standalone.gypi:81 defaults it to "vfpv3", which causes CAN_USE_VFP3_INSTRUCTIONS to be defined, which causes a build error on ARMv6 (e.g., Raspberry Pi): /bin/sh: line 1: 28983 Illegal instruction These are the preprocessor defines you get if you allow arm_fpu to assume its default value: '-DENABLE_DEBUGGER_SUPPORT' '-DV8_TARGET_ARCH_ARM' '-DCAN_USE_VFP2_INSTRUCTIONS' '-DCAN_USE_VFP3_INSTRUCTIONS' '-DUSE_EABI_HARDFLOAT=1' '-DBUILDING_V8_SHARED' '-DV8_SHARED' If you define arm_fpu to be empty, then CAN_USE_VFP3_INSTRUCTIONS can still be enabled by setting arm_neon=1, which is why I added the "neon" USE flag. > Same for neon - I'd prefer to have a separate bug for neon support, and > focus on the compile issue here. I'd prefer to avoid making these two > changes simultaneously since it's harder to debug failures then (determine > which change broke the build). It's not too practical to separate the Neon change unless you're willing to introduce a new "vfpv3" USE flag to allow the use of VFPv3 instructions without enabling Neon. As is, in order to make the build work on ARMv6, I have to disable the use of VFPv3 instructions. There has to be a way for the user to enable them, or this patch will introduce a regression. Ideally, this ebuild should have IUSE+="neon vfpv3" and myconf+=" $(gyp_use vfpv3 arm_fpu vfpv3 vfpv2) $(gyp_use neon arm_neon)", but if you don't want to create a new "vfpv3" USE flag, then implying VFPv3 with the "neon" flag is the best we can express.
Patch applied, thanks!
I think it would have been better to separate neon and vfp3. Now you cannot build with vfp3 support in armv6 profile (because neon is masked), nor on armv7 systems that don't support neon (e.g. OLPC XO-1.75).
(In reply to comment #6) > I think it would have been better to separate neon and vfp3. Now you cannot > build with vfp3 support in armv6 profile (because neon is masked), nor on > armv7 systems that don't support neon (e.g. OLPC XO-1.75). Please open a separate bug, preferably with patches.
