Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assembly private symbols redefinition error #27395

Closed
JustAPerson opened this Issue Jul 30, 2015 · 6 comments

Comments

Projects
None yet
5 participants
@JustAPerson
Copy link
Contributor

JustAPerson commented Jul 30, 2015

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

This comment has been minimized.

Copy link
Contributor

nagisa commented Jul 30, 2015

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

This comment has been minimized.

Copy link
Contributor Author

JustAPerson commented Jul 31, 2015

@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

This comment has been minimized.

Copy link
Contributor

nagisa commented Jul 31, 2015

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

This comment has been minimized.

Copy link
Member

steveklabnik commented Aug 4, 2015

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

@brson

This comment has been minimized.

Copy link
Contributor

brson commented Jan 26, 2017

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

@Mark-Simulacrum

This comment has been minimized.

Copy link
Member

Mark-Simulacrum commented May 20, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.