Add thumbv7neon-* targets.

[Alexhuszagh]

Add the thumbv7neon-linux-androideabi and thumbv7neon-unknown-linux-gnueabihf targets.

Closes #254.

[Alexhuszagh]

bors try --target thumbv7neon-unknown-linux-gnueabihf

[Alexhuszagh]

That they correctly use Thumb-2 mode and have ARMv7 architecture with NEON support can be checked by the following: $a relocations mean ARM-mode relocations, $t relocations mean THUMB-mode relocations. Running this over a compiled binary shows there are effectively no ARM-mode relocations, but plenty of THUMB-mode ones.

$ objdump --syms /path/to/binary | grep '$a'
...
000028b4 l       .plt   00000000              $a
...
$ objdump --syms /path/to/binary | grep '$t'
...
00002ac0 l       .plt   00000000              $t
...
$ readelf -A /path/to/binary
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv4
  Tag_Advanced_SIMD_arch: NEONv1 with Fused-MAC
  Tag_ABI_PCS_GOT_use: GOT-indirect
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_enum_size: int
  Tag_ABI_VFP_args: VFP registers
  Tag_CPU_unaligned_access: v6
  Tag_ABI_FP_16bit_format: IEEE 754

Which is our expected output: HF (as detected by VFP registers), 7-a architecture, Thumb-2, and NEONv1 SIMD instructions. The binaries also run in qemu. I'll try to work on thumv7neon-linux-androideabi later.

Not sure if we have to specify AR_thumbv7neon_unknown_linux_gnueabihf=arm-linux-gnueabihf-ar, since the Android image failed if this wasn't defined. However, this works perfectly fine with a C++-compiled crate.

[Alexhuszagh]

OK I'm pretty certain the failing runner is due to the older Qemu version: we need Cortex-A12 or higher to support these thumbv7neon features I believe, and Qemu 5.10 only supports up to Cortex-A9. See the features of ARM processors. I might be able to get the Android version to work by updating the Qemu version. Nevermind. Still fails.

UPDATE: Turns out this is a docker issue. Adding DOCKER_OPTS=--privileged" fixes this with docker or podman, as does DOCKER_OPTS="--security-opt seccomp=unconfined". I'll see if there's a way to whitelist on personality`, as described here.

Adding the following seccomp profile should work:

{
  "names": [
    "personality"
  ],
  "action": "SCMP_ACT_ALLOW"
}

But then we need to provide this properly, which means we might need a data directory or something so we can write the seccomp profile and then use it when passing to the container.

[bors]

try

Build succeeded:

• conclusion

[Alexhuszagh]

bors try --target thumbv7neon-linux-androideabi --target thumbv7neon-unknown-linux-gnueabihf --target thumbv7neon-unknown-linux-musleabihf

[Alexhuszagh]

bors cancel
bors try --target thumbv7neon-linux-androideabi --target thumbv7neon-unknown-linux-gnueabihf

[bors]

try

Already running a review

[Alexhuszagh]

Update: Forgot that thumbv7neon-unknown-linux-musleabihf is tier 3, and therefore needs to have Rust compiled for it..

[Alexhuszagh]

bors try --target thumbv7neon-linux-androideabi --target thumbv7neon-unknown-linux-gnueabihf

[bors]

try

Already running a review

[bors]

try

Build succeeded:

• conclusion

[otavio]

Anything still pending for this?

[Alexhuszagh]

@otavio Don't believe so, if the changes look good we should be able to merge. I've checked the readelf architecture output and it looks good.

[otavio]

bors r+

[Alexhuszagh]

bors r-

This is going to conflict with #746, going to have to rebase it slightly. I'll merge this with bors r=Otavio when the other is merged and this is rebased.

[bors]

Canceled.

[Alexhuszagh]

EDIT: I may be wrong. My mistake, I think I undid those issues. I guess the seccomp isn't going to conflict.

bors r=Otavio

[bors]

Build succeeded:

• conclusion