Assembly private symbols redefinition error

[JustAPerson]

On playpen nightly

#![crate_type="lib"]
#![feature(asm)]

fn main() {
    unsafe {
        routine()
    }
}

pub unsafe fn routine() {
    asm!("mov ecx, 0xFF
          .loop:
          loop .loop"
          : // no outputs
          : // no inputs
          : "ecx"
          : "intel");
}

pub unsafe fn routine2() {
    routine(); // causes inlining, duplicating the symbol improperly
}

<anon>:11:5: 17:22 error: <inline asm>:3:11: error: invalid symbol redefinition
          .loop:
          ^

<anon>:11     asm!("mov cx, 0xFF
<anon>:12           .loop:
<anon>:13           loop .loop"
<anon>:14           : // no outputs
<anon>:15           : // no inputs
<anon>:16           : "ecx"
          ...
error: aborting due to previous error
playpen: application terminated with error code 101

The following two conditions are necessary to trigger this:

• Generating a library ( #![crate_type="lib"] )
• At least -C opt-level=2

Without both of these, the error does not occur.

[nagisa]

In the inline assembly you are not supposed to use whatever names you want for labels. You must use something like this instead:

1:
jmp 1b

and

jmp 1f
1:

where 1b refers to label 1 defined previously and 1f refers to label 1 defined later. Otherwise the compiler has not enough information to mangle your labels in case of optimisations.

[JustAPerson]

@nagisa,

Ahh, thank you!
Perhaps rust should reject non-numeric labels then?
Does rust currently do any introspection of inline assembly before giving to llvm?

[nagisa]

Does rust currently do any introspection of inline assembly before giving to llvm?

Almost none. I’m doubtful we want to introspect assembly either.

Perhaps rust should reject non-numeric labels then?

Doubtful. Inline assembly is an escape hatch to do whatever you want. You’re responsible for the errors you cause yourself. There’s at least one more way to make this error go away by annotating the function as #![inline(never)] and that’s for you to decide how you want to fix it.

Note that inline assembly is an unstable feature and we are not even sure if the current design the correct one; that is, many things might change before it becomes stable.

[steveklabnik]

Yes, I am not sure that this is something that's fixable...

[brson]

Anybody want to make a decision about whether there's a bug here or not?

[Mark-Simulacrum]

I'm going to say that this is not a bug.

[Aloxaf]

I met the same problem, but #27395 (comment) get a error: invalid operand for instruction now. ( on Linux x64 )

Finally I found out that adding ${:uid} to the label name can solve this problem.

eg.

.L1${:uid}
jmp .L1${:uid}

Reference: https://llvm.org/docs/LangRef.html#inline-assembler-expressions