Targeting ARMv6 produces an ARMv7 binary #792
Comments
|
Please include some snippets from the build output that show what command line arguments are being passed to the C compiler when compiling C code and when assembling. |
|
Below is trimmed-down output from ring's build. I cut out a few environment variables and a bunch of nearly-identical GCC invocations. Let me know and I'll edit the post with full output. Based on this output and the results from readelf, I noticed a pattern. Although most objects are being compiled correctly to ARMv6, the following pregenerated assembly files are being compiled to ARMv7:
It seems strange that GCC would produce ARMv7 objects even when |
|
Could be a red herring but it could be something too: Most of the the |
|
I think @pietro's comment probably identified the issue. @reynoldsbd can you revert that commit and see if that fixes the issue for you? My understanding is that the RPi team recommends a particular ARMv6 toolchain (based on GCC) that, when used, will generate executables that work on every RPi device from Zero to 3. Ideally, when building ring with this toolchain, we'd include the ARMv7 (specifically NEON) optimized code. That way, the code runs at maximum performance on each device based on runtime feature detection. To make that work, we'll need to look more closely at how the OpenSSL (not BoringSSL) project deals with this kind of issue. I think BoringSSL is only interested in ARMv7+ AFAICT. Now, if you are targetting RPi Zero specifically you probably would rather NOT include the ARMv7 code (especially NEON) because it's just a waste. In order to support that, we'd probably need to modify the assembly modules to compile the ARMv7 code only when #if ARM_MAX_ARCH>=7. It looks like that is actually already done. So, maybe we just need to put WDYT? |
Actually, in aes.rs and gcm.rs, we'd need to change the conditions in |
|
Good news: after rebooting and setting up a clean build environment, my cross-compiled binaries are now running without crashing on the Pi Zero. Sorry for the false alarm! |
|
@briansmith I appear to have this same issue - did any changes occur as a result of this original report? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As with #516 and #578, I am having trouble building an ARMv6 binary (for a Raspberry Pi Zero) when ring is involved. My application builds successfully, but the resulting binary seems to be for ARMv7 rather than ARMv6 (according to
readelf -A).Further details:
stable-x86_64-unknown-linux-gnu(1.32), and my target isarm-unknown-linux-gnueabihflinker = "arm-linux-gnueabihf-gcc"in my Cargo configAccording to
find target/arm-unknown-linux-gnueabihf/deps -type f | xargs readelf -A, it appears that several - but not all - of ring's native object files are being built for ARMv7, and I think this is causing the final linking of my application to use ARMv7 instead of ARMv6.The text was updated successfully, but these errors were encountered: