asm! should automatically rewrite labels in assembly code

[Amanieu]

Defining labels in inline assembly is broken because inlining, function cloning and other compiler optimizations may result in an asm! block being emitted more than once in the final binary. This can cause duplicate symbol errors or even compiler crashes (#74262). For this reason it is recommended to only use GAS local labels when using asm! (#76704).

To improve user experience when using asm!, rustc should automatically rewrite label names into a unique name. For example:

asm!(
    "popcnt {popcnt}, {v}",
    "loop:",
    "blsi rax, {v}",
    "jz exit",
    "xor {v}, rax",
    "tzcnt rax, rax",
    "stosb",
    "jmp loop",
    "exit:",
    v = inout(reg) value => _,
    popcnt = out(reg) popcnt,
    out("rax") _, // scratch
    inout("rdi") bits.as_mut_ptr() => _,
);

rustc should search for lines beginning with <ident>: to find label names and then replace all instances of <ident> in the assembly code with .Lasm_label_<ident><unique id>. The .L instructs the assembler that the label is local to the current compilation unit and should never be exported, even as a debug symbol. The unique ID can be generated by LLVM using ${:uid} and is guaranteed to be unique within the current compilation unit.

[nagisa]

Any reason to bother with .L and ${:uid} instead of just replacing them with numbered labels?

[Amanieu]

Internally the assembler will turn numbered labels into .L local symbols. Doing it directly makes the implementation slightly simpler since we don't need to track whether a label is before or after a particular instruction.

[asquared31415]

@rustbot claim

[Amanieu]

@asquared31415 Thanks for taking up this issue!

I would suggest doing the rewriting in the backend in compiler/rustc_codegen_llvm/src/asm.rs.

[asquared31415]

I already have an implementation working in the simple cases, and was about to submit a pr when I realized it is going to be a lot more work to fix the edge cases and that I should claim these issues so someone else doesn't try to work on them too

[joshtriplett]

Reposting a comment that I left on #81570:

Forcing all labels within an asm block to be local would certainly improve usability for the common case (so that people don't have to use local labels).

However, it is legal in clang and gcc to define a label in an asm block and make that label a global symbol. And I've seen that used, on occasion, in real projects, including the Linux kernel. (For instance, suppose you want a global symbol pointing to a location that can be overwritten as a "probe point".) Rewriting would cause such code to silently "work" while making a global symbol with the wrong name, rather than catching the issue.

I agree that such code is not especially safe, if you're not certain that the asm code will appear in the binary exactly once. (In C that's a little easier to guarantee.) It's safer in global_asm, and I do think that we should support it there eventually.

In the meantime, I personally would prefer to make a best-effort attempt to catch the use of non-local labels in asm! and error on them, rather than attempting to rewrite them (which requires more careful lexing of inline assembly). Alternatively, if the thought is that we might allow global labels in the future, perhaps we could attempt to lex a little more of the inline assembly, catch attempts to use .globl or .global, and emit an error when applying those directives to a label.

I would prefer to just reject non-local labels.

[asquared31415]

That approach would work, and perhaps be better for allowing future choices. We can always remove an error and make something work later, but if this causes weird behavior, it's a little harder to revert, especially if people rely on it. As discussion in #81570 progressed I have become more concerned about enforcing things that are wrong, or preventing the use of things that should work, so I support making them a compiler error for now and having a proper discussion about what asm! should do in regards to labels.

Perhaps it would be a good idea to catch .global along with the syntax flags as in #79869 and also look for non-local labels and suggest a fix if possible for the labels too. I had already been glancing at #79869 and would be willing to try making it error instead. I would need a little direction here, as I am not certain where the error should be detected and how to emit compiler errors.

I think that if it is decided that we should error on global labels rather than rewrite, #81570 should be closed no matter the decision on the detection of .global, as that pr's goal was to remove the errors and crashes, whereas changing to erroring on labels would only remove a crash and change the error.

[Amanieu]

There is a precedent for label rewriting: Clang does this for labels in MS-style inline asm (source), which is what inspired me to suggest this.

Clang is a bit smarter than us since it uses LLVM MC to actually parse the asm as it is rewriting, but it also does a lot more than us (e.g. inferring operand & constraints). Also this LLVM support only exists for x86, so it wouldn't be suitable for us.

I still think that automatic label rewriting is the best thing we can do at the moment. We should certainly lint against the use of .global/.globl in the same way as #79869. This will help with people accidentally expecting exported label names to work.

[comex]

Sure, but MS-style inline asm is overall quite a bit more magic than GNU-style inline asm.

GNU-style inline asm has always been passed straight through to the assembler, except for making substitutions where substitutions are requested. In the case of GCC, or Clang with -fno-integrated-as, this is done without even validating it in any way: you can take a C file containing asm("do a barrel roll");, pass it to gcc -S, and get an "assembly" file with do a barrel roll pasted in the middle of a function. This is a desirable property, since it allows inline asm to use instructions which are known to an external assembler but not the compiler.

While rewriting labels doesn't directly affect that use case, it still violates the principle of transparency. Users expect assembly inside asm! to have the same syntax as standalone assembly, not "the same syntax except for this one magic feature". And this will become more confusing if global_asm! is added.

Also, if naked functions are stabilized, defining a global symbol within asm! might be a reasonable thing to do in those (though I think some guarantees about compilation model would need to be worked out before it could really have well-defined semantics).

There's also the "cowboy code" concern mentioned by @joshtriplett. He said that ensuring asm code would appear only once is "a little easier to guarantee", but I don't think that's quite right. In both Rust and GNU C, it is impossible to guarantee inline assembly will be instantiated exactly once (not counting global inline assembly and perhaps naked functions), because the compiler is always allowed to duplicate code within a function. But Linux does it anyway, because that's their attitude toward a lot of compiler things.

People might attempt the same in Rust. Personally, I'd prefer if rustc didn't go out of its way to break it; after all, if the compiler does decide to duplicate the asm, the result will be an assembler error, not UB. I suspect others might strongly prefer if rustc did go out of its way to break it. Regardless, it's a problem if it seems to work but does something unexpected due to the rewriting.

Finally, this kind of semi-blind scanning of assembly code is impossible to make robust. For example, it's perfectly legal for a label to have the same name as an instruction (jmp: jmp jmp).