arm-unknown-linux-gnueabihf generates armv7 instructions

[ddemarco5]

I'm working on a dual platform embedded project. One is running an ARMv7 processor, and one is running on ARMv6 (RPI1 B+).
The ARMv7 platform runs without issue, however, trying to get ARMv6 code generated has caused problems.
When running the binary on the ARMv6 target, I fail with an illegal instruction.
Tracing on it reveals cbz r3, 0x7f55a264, a compare and branch on 0... an ARMv7 instruction, absent from the ARMv6 instruction set.

Here is my target in the cargo config:

linker = "arm-linux-gnueabihf-gcc"
rustflags = [
	#"-Ctarget-cpu=generic",
	"-Ctarget-feature=+armv6",
	"-Clink-args=-march=armv6"
	]

The broadcom SOC isn't an available target-cpu (oddly, all the cpus in the target list are armv7 processors), so I tried generic, I've tried enabling the armv6 feature and disabling a handful of armv7 features, but had no luck. I've passed args to the linker to ensure the target arch is indeed armv6 as far as it's concerned, but armv7 instructions are still getting through.

I've tried a couple options, but the supported targets list at https://forge.rust-lang.org/platform-support.html
arm-unknown-linux-gnueabihf | ✓ | ✓ | ✓ | ARMv6 Linux, hardfloat
is misleading.

Is there a way to disable all target-features except the ones you explicitly enable? That might be a possible workaround for the time being.

[parched]

Hi @ddemarco5, just to be sure, have you checked if this happens in rust code not C code?

Also, the target cpu you want for the RPi1 is arm1176jzf-s.

[ddemarco5]

@parched this is compiling rust code with rustc via cargo, not compiling any C code to my knowledge.

I set the target cpu to arm1176jzf-s, outcome didn't change.

[arielb1]

@ddemarco5

Could you find out from which function did the problem instruction come from, by using objdump -rld on the binary and searching for the offending instruction?

[ddemarco5]

The instruction that hits first is in "deregister_tm_clones", but it appears elsewhere as well.

Here's the output of a grep on the file for cbz. I'd be happy to upload the full file if anyone needs it.

    5260:	b103      	cbz	r3, 5264 <deregister_tm_clones+0x1c>
    5294:	b103      	cbz	r3, 5298 <register_tm_clones+0x20>
    52be:	b123      	cbz	r3, 52ca <__do_global_dtors_aux+0x1e>
   8cdf8:	b11b      	cbz	r3, 8ce02 <atexit+0x12>
   8ce14:	b103      	cbz	r3, 8ce18 <__pthread_atfork+0x8>

[parched]

@parched this is compiling rust code with rustc via cargo, not compiling any C code to my knowledge.

Yes but the standard library depends on C code, e.g., libc, and the compiler also generates calls to it's own runtime, some of which are written in C.

I set the target cpu to arm1176jzf-s, outcome didn't change.

arm-unknown-linux-gnueabihf should just work anyway so I wouldn't expect setting the target cpu to make a difference here, it just helps the compiler possibly generate more optimal code for that cpu.

[parched]

The instruction that hits first is in "deregister_tm_clones", but it appears elsewhere as well.

I think that's in the C runtime startup code so I suspect you are using a Armv7 toolchain (which most named arm-unknown-linux-gneabihf-gcc are). Where did you get this compiler from?

[parched]

Also what Linux distribution are you using on the RPi1? To my knowledge, there aren't any hard-float distros for RPi1, so maybe you want to use the arm-unknown-linux-gnueabi rust target.

[ddemarco5]

I pulled gcc-arm-linux-gnueabihf from the standard debian repos. I'm using the newest version of raspbian on the pi. I'll try without the hardfloat.

[jonas-schievink]

There are plenty of hard-float distros, Raspbian uses hard floats, as does Arch Linux ARM. I'm deploying to a similar target locally (RPi 1 Model B) and successfully use the arm-unknown-linux-gnueabihf target.

[ddemarco5]

I checked my distro and it does in fact use hardfloat, so I stopped trying to compile it for the softfloat target. I'm currently operating under the assumption that the arm-unknown-linux-gnueabi compiler I have is an armv7 version. I'm trying to get a different version.
@jonas-schievink can you paste your uname -a and /proc/cpuinfo?

[jonas-schievink]

Sure:

jonas@jonas-raspi ~> uname -a
Linux jonas-raspi 4.9.52-1-ARCH #1 SMP Sat Sep 30 01:00:26 UTC 2017 armv6l GNU/Linux
jonas@jonas-raspi ~> cat /proc/cpuinfo
processor	: 0
model name	: ARMv6-compatible processor rev 7 (v6l)
BogoMIPS	: 697.95
Features	: half thumb fastmult vfp edsp java tls 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xb76
CPU revision	: 7

Hardware	: BCM2835
Revision	: 0002
Serial		: 000000002fdbf225

Note that I'm using nightly-2017-09-15, not the current nightly (haven't checked if that one works).

[ddemarco5]

I'm building a toolchain specific to the RPI B+. If that solves the issue I'll go ahead and close the issue, as it appears to be a problem of libc being compiled for ARMv7.