This repository has been archived by the owner on Apr 22, 2023. It is now read-only.
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
build: improve armv7 / hard-float detection
- Loading branch information
1 parent
b0c0111
commit 90efdb3
Showing
1 changed file
with
62 additions
and
6 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
90efdb3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, it seems rather strange, but this patch makes the build on the Raspberry Pi result in an invalid binary using the default configuration.
When I compile the v0.8.4 tag, using the env flags specified here: https://gist.github.com/3119325, then node works fine.
But when I apply this patch and attempt to compile again (using the same env flags), then attempting to invoke the resulting "node" results in "Illegal Instruction", and the only symbol mention in the gdb backtrace is
OPENSSL_cpuid_setup
.Seems strange to me, but I thought I'd let you know of my discovery.
90efdb3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TooTallNate Is that from the bundled or the system openssl library? Can you post a backtrace and the output of
ldd path/to/node
?90efdb3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bnoordhuis It's the system openssl. The build fails trying to compile openssl if you try to use the bundled one (I could open a separate issue for that if you'd like). The result of
ldd ./node
is identical in both the working version (without this patch) and the non working version.90efdb3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, someone else reported that issue as well (that was before this patch though). The best advice I can give you is to not link against the system openssl, I speculate it's an ABI mismatch.
90efdb3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That should be fixed, yes, so please open an issue.
90efdb3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not exactly related to the problem @TooTallNate is seeing, but apparently V8 has trouble with hard float systems that don't support VFP3, which is exactly what will happen on a Raspberry Pi with hard-float and this patch correctly sets v8_use_arm_eabi_hardfloat however v8 defines
CAN_USE_VFP_INSTRUCTIONS
whenv8_use_arm_eabi_hardfloat=="true"
in common.gypi, causing V8 to emit VFP3 instructions that the device doesn't support.It seems to be a popular belief that hardfp requires VFP3 instructions, when the Raspberry Pi is in fact hardfp without VFP3 (but it does have VFP2).
Originally I thought that because it's not being defined when manually setting
-DUSE_EABI_HARDFLOAT
inCCFLAGS
like https://gist.github.com/3119325, V8 doesn't generate any VFP3 instructions and that's probablly why that build works, however we can't simply remove the CAN_USE_VFP_INSTRUCTIONS declaration when hardfloat is true because there are many places where the ARM codegen assumes VFP3 instructions when hardfloat is enabled. Attempting to remove it produces the output seen at https://gist.github.com/3244239, following the backtrace we can see that it is caused in code-stubs-arm.cc. Qt seem to have a patch supporting VFP2 instructions (which the Rapsberry Pi does support) listed at https://codereview.qt-project.org/#change,27256.Upstream issue: http://code.google.com/p/v8/issues/detail?id=2168
I have yet to attempt to compile for Raspberry Pi with Qt's patches, I think that is what I will try next.
90efdb3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just spent over an hour composing a great reply to this thread full of research on the issue and related issues, all for Chrome and GitHub to conspire against me and lose the whole lot when clicking comment. Feel so gutted.
I think the gist of it was, not sure if its the same issue that @TooTallNate was having but I found that V8 thinks hardfp means that you have VFP3, so it generates VFP3 instructions causing lots of problems on ARMv6 which doesn't support VFP3 but can support hard float and VFP2 instead. You can't just remove the USE_VFP_INSTRUCTIONS define in common.gypi (that's where it's set because of the earlier stated assumption, and is exacerbated by this commit as it starts to correctly set v8_use_arm_eabi_hardfloat) because then you get this as other parts of the ARM codegen assume that hardfp means VFP3 available, and then the internal checks fail. The proper way to go about this seems to use VFP2, and Qt has a patch for VFP2 that might work at https://codereview.qt-project.org/#change,27256, but I am yet to try it and requires some back-porting to V8 and there's the licensing issues apparently. None of this should be a problem on soft float systems or hard float but ARMv7/VFP3 supported, just for the odd combination that is the Raspberry Pi.
The upstream issue I found for this stuff is: http://code.google.com/p/v8/issues/detail?id=2168
90efdb3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoops, that's embarassing. Uber cache fail. Anyway, for reference:
Applying the Qt patches in adammw/node@3a42578 seems to produce a binary that works on Raspbian (hard float OS for Raspberry Pi). Tested by cross-compiling with ./configure --without-ssl --without-snapshot. Binaries produced uploaded to https://gist.github.com/3245130
Running the tests - some succeed, some fail, tests eventually crashed with IOError: [Errno 11] Resource temporarily unavailable, similar to issue #3810.
90efdb3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Issue #3755 also seems related to this.