[thumbv6m-none-eabi] LLVM ERROR: unsupported relocation on symbol

[japaric]

STR

$ cargo new --bin app && cd $_

$ edit src/main.rs && cat $_
#![feature(asm)]
#![feature(lang_items)]
#![no_main]
#![no_std]

#[no_mangle]
pub fn _start() -> ! {
    unsafe {
        asm!("b foo");
    }

    loop {}
}

#[no_mangle]
pub fn foo() {}

#[lang = "panic_fmt"]
fn panic_fmt() {}

#[no_mangle]
pub fn __aeabi_unwind_cpp_pr0() {}

# Instead of Xargo, you could explicitly depend on (rust-src's) core and just use Cargo
$ xargo rustc --target thumbv6m-none-eabi --verbose -- -C link-arg=-nostartfiles
   Compiling app v0.1.0 (file:///home/japaric/tmp/app)
LLVM ERROR: unsupported relocation on symbol
error: Could not compile `app`.

To learn more, run the command again with --verbose.

Works fine with thumbv7m-none-eabi:

$ xargo rustc --target thumbv7m-none-eabi --verbose -- -C link-arg=-nostartfiles && echo OK
OK

This is a bug in LLVM (30279) that has already been fixed in r280651. We only have to backport the fix.

cc @alexcrichton @thejpster

[nagisa]

Seeing the reproduction involves assembly and jumping to a label that hasn’t been passed as an input for the asm!, I do not think this deserves a backport.

[japaric]

I do not think this deserves a backport.

I meant backporting/cherry-picking the upstream fix into our LLVM fork; not a "beta-backport". People that use the thumbv*-none-eabi* targets make pretty much exclusive use of the nightly channel (because Xargo, unstable features, etc.) so whether a fix makes it faster to the stable/beta channel doesn't really make much difference to us.

jumping to a label that hasn’t been passed as an input for the asm!

Honest question: How does one pass a function to asm! with the goal of using it as a label? And does that handle the mangling of the function?

[nagisa]

Honest question: How does one pass a function to asm! with the goal of using it as a label? And does that handle the mangling of the function?

There’s no support for doing that directly in LLVM sadly, mostly because this is not a very desired feature; and you can work around the issue with some indirection, which not only handles mangling but also any relocation business you might have going on (pardon my x86):

#![feature(asm)]

fn boom() {
    ::std::process::exit(42)
}

fn main() { unsafe {
    asm!("jmpq *$0" : : "r"(boom as fn()));
} }

compiles to code like this (PIC)

	lea	rax, [rip + _ZN8rust_out4boom17he6750988c06a519cE]
	jmp	rax

or

movl	$_ZN4test4boom17h7dba417bfc620c55E, %eax
jmpq	*%rax

in static relocation mode.

[japaric]

Clever. The ARM asm parser doesn't seem to like the dereference though:

error: <inline asm>:1:5: error: unexpected token in operand
        bl *r0
           ^

 --> src/main.rs:9:9
  |
9 |         asm!("bl *$0" : : "r"(foo as fn()));
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

[parched]

@japaric to branch to an address in a register can do

asm!("blx $0" : : "r"(foo as fn()));

but if you want to branch to a label you need an integer constant constraint.

asm!("bl $0" : : "i"(foo as fn()));

[japaric]

but if you want to branch to a label you need an integer constant constraint.

Thanks, @parched. That works nicely and will let me hide more symbols in some crates like f3 \o/.

(Using "b $0" with the thumbv6m target still needs #38411 though)