I’ve been doing some reading up about Rust’s support for Android, and it seems that now it is essentially a Tier 1, but I’m not sure if Rust’s Android targets quite match up with Android’s ABI.
Both arm-linux-androideabi and armv7_linux_androideabi seem to be targeting arm-v7a, except armv7 also enables thumb2 mode and disables NEON.
Shouldn’t they both disable NEON? And shouldn’t arm-linux-androideabi not be targeting v7?
At this point it might not be a big deal, given the world has moved on to arm-v7a and aarch64, but for those not very familiar with the back-end of the compiler, including myself, this might lead to surprising behavior.
The +thumb2 is redundant in that target spec as it’s already included in v7, and it doesn’t enable thumb mode, it only indicates that the processor supports it.
Disabling neon for the other arm target isn’t needed AFAIK because it’s not included in v6.
When the armv7-android-linuxeabi target was added, the plan was to eventually change Rust’s arm-linux-androideabi target to no longer target ARMv7 but instead to match Android’s armeabi ABI. This wasn’t done immediately in order to allow time for existing crates to migrate to the new ARMv7 target. That was about six months ago; it’s probably a good time to push forward with this.
The +thumb2 is redundant in that target spec as it's already included in v7, and it doesn't enable thumb mode, it only indicates that the processor supports it.
I see! In that case, what instructions does it generate by default? Is it configurable? AFAICT it should be generating thumb by default to match the NDK.
Disabling neon for the other arm target isn't needed AFAIK because it's not included in v6.
Except right now it seems to be targeting v7. @mbrubeck, that would be a great change since it would make it consistent with the expectations from the NDK.
No, you need another target to generate thumb instructions, one where the llvm-target starts with thumb not arm. However, it's not clear to me that thumb code is required or optional reading that abi.
Ah yes, I was looking at the normal linux arm target, arm-linux-androideabi is indeed broken.
OK, I see. On the NDK page for armeabi it mentions that
The NDK generates Thumb code by default unless you specify different behavior using the LOCAL_ARM_MODE variable in your Android.mk file.
The documentation for that flag further mentions:
LOCAL_ARM_MODE
By default, the build system generates ARM target binaries in thumb mode, where each instruction is 16 bits wide and linked with the STL libraries in the thumb/ directory. Defining this variable as arm forces the build system to generate the module's object files in 32-bit arm mode.
It's not entirely clear if this is enabled for v7a as well, but a quick test with the latest NDK could answer that. I could do that test once I have access to my dev computer after the holidays.
How does the Rust community feel about making the default thumb to match up with the NDK's behavior? And, does this matter that much aside from code size? I.e. Are there significant compatibility issues from mixing the two modes?
Not knowing much about the compiler at all, what would be involved in doing something similar to LOCAL_ARM_MODE if we wanted to integrate Rust into an NDK project?
