armhf binaries still use NEON

[cuviper]

I was just investigating a report that Fedora's rust binaries for armv7hl use NEON, but they should not per #35590, supposedly fixed in #35814. (Fedora's build is 1.11, but I applied that patch.) I can see the exact same issue in the latest official rustc-nightly-armv7-unknown-linux-gnueabihf.tar.gz, whose version file says 1.14.0-nightly (289f3a4ca 2016-09-29).

# arm-linux-gnu-objdump -d libstd-*.so | grep '<.*lang_start.*>:' -A30
0006ccf0 <_ZN3std2rt10lang_start17hdfc48bc748089cb2E>:
   6ccf0:       e92d4ff0        push    {r4, r5, r6, r7, r8, r9, sl, fp, lr}
   6ccf4:       e24ddf45        sub     sp, sp, #276    ; 0x114
   6ccf8:       e1a09001        mov     r9, r1
   6ccfc:       e1a0b000        mov     fp, r0
   6cd00:       e3a0000d        mov     r0, #13
   6cd04:       e3a01001        mov     r1, #1
   6cd08:       e1a0a002        mov     sl, r2
   6cd0c:       ebff5534        bl      421e4 <signal@plt>
   6cd10:       e3700001        cmn     r0, #1
   6cd14:       0a000134        beq     6d1ec <_ZN3std2rt10lang_start17hdfc48bc748089cb2E+0x4fc>
   6cd18:       e59f0788        ldr     r0, [pc, #1928] ; 6d4a8 <_ZN3std2rt10lang_start17hdfc48bc748089cb2E+0x7b8>
   6cd1c:       e08f0000        add     r0, pc, r0
   6cd20:       ebff5856        bl      42e80 <_ZN5alloc3oom15set_oom_handler17hfc02679a00c1734eE@plt>
   6cd24:       e3a0001e        mov     r0, #30
   6cd28:       ebff5509        bl      42154 <sysconf@plt>
   6cd2c:       e1a07000        mov     r7, r0
   6cd30:       e28d0050        add     r0, sp, #80     ; 0x50
   6cd34:       f2c00050        vmov.i32        q8, #0  ; 0x00000000
   6cd38:       e3a06000        mov     r6, #0
   6cd3c:       e1a01000        mov     r1, r0
   6cd40:       f4410acd        vst1.64 {d16-d17}, [r1]!
   6cd44:       f4410acf        vst1.64 {d16-d17}, [r1]
   6cd48:       e58d6070        str     r6, [sp, #112]  ; 0x70
   6cd4c:       ebff57d1        bl      42c98 <pthread_attr_init@plt>
   6cd50:       e59f1754        ldr     r1, [pc, #1876] ; 6d4ac <_ZN3std2rt10lang_start17hdfc48bc748089cb2E+0x7bc>
   6cd54:       e28d8c01        add     r8, sp, #256    ; 0x100
   6cd58:       e58d0100        str     r0, [sp, #256]  ; 0x100
   6cd5c:       e3500000        cmp     r0, #0
   6cd60:       e58d80f4        str     r8, [sp, #244]  ; 0xf4
   6cd64:       e08f1001        add     r1, pc, r1

In particular, they flagged that vmov.i32 q8, #0 as a problem. I'm no ARM expert, but from this it appears the qN registers are NEON-only. I believe those instructions using {d16-d17} are also a problem, because with VFP3-D16 we should only have d0 to d15.

[alexcrichton]

Hm looks like it's definitely still there:

$ rustc +nightly --print cfg --target armv7-unknown-linux-gnueabihf | grep neon
target_feature="neon"

[cuviper]

( TIL of rustc +nightly! 😮 )

[cuviper]

Just to confirm:

$ rustc +nightly -V
rustc 1.14.0-nightly (3210fd5c2 2016-10-05)
$ rustc +nightly --print cfg --target armv7-unknown-linux-gnueabihf | grep feature
target_feature="vfp2"
target_feature="vfp3"

No neon. This doesn't explicitly mention d16 vs. d32 though.

I ran objdump -d on all binaries in rustc-nightly-armv7-unknown-linux-gnueabihf.tar.gz. I see no mention of NEON qN registers. I see uses of d0-d15, but no higher, so I think +d16 is OK too.

I'll know better if someone with a limited armv7 actually tries to run this, but LGTM! ✔️

[alexcrichton]

Thanks for the confirmation @cuviper!