Skip to content

emit .att_syntax when global/naked asm use that option #143599

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

folkertdev
Copy link
Contributor

fixes #143542

LLVM would error when using -Cllvm-args=-x86-asm-syntax=intel in combination with global/naked assembly with att_syntax. It turns out that for LLVM you do in this case need to emit .att_syntax.

r? @Amanieu

@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 7, 2025
@folkertdev folkertdev force-pushed the x86-asm-syntax-global-naked-asm branch from 2d97a2b to 8294047 Compare July 8, 2025 05:42
@@ -431,7 +435,11 @@ impl<'tcx> AsmCodegenMethods<'tcx> for CodegenCx<'_, 'tcx> {
}
}
}
if intel_syntax {

// Just to play it safe, reset the assembly syntax to att.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't this cause issues when -Cllvm-args=-x86-asm-syntax=intel is used? LLVM might still be trying to emit intel syntax asm for functions it compiles.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LLVM doesn't emit asm as text, it emits the instructions directly and ignores the syntax. This only potentially affects inline asm in C code which would probably break anyways because most C code expects AT&T syntax for inline asm.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well it works in the test? I believe what is really happening is that every asm block is isolated, given that LLVM parses the assembly anyway.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LLVM doesn't emit asm as text, it emits the instructions directly and ignores the syntax.

I think it would also break --emit asm producing valid assembly. Or does LLVM parse the asm blocks and then emit them as strings in the other format again?

Well it works in the test? I believe what is really happening is that every asm block is isolated, given that LLVM parses the assembly anyway.

LLVM definitively merges global asm blocks (unfortunately). For example assembler macros leak between global asm blocks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The parsing at least seems to happen independently? Anyway this was already what we emitted, and the problem that got reported is that .att_syntax just got ignored, which this PR fixes.

if intel_syntax {
template_str.push_str(".intel_syntax\n");

// Select the assembly syntax. On non-X86 platforms att is used by default, on X86 we use
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Slight correction to the comment: the name AT&T refers specifically to an x86 asm syntax. There is no such thing as AT&T syntax on non-x86 platforms.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh, I've always thought of it as intel and "the other one". At least s390x, powerpc, etc seem more inspired by AT&T.

Anyway, I rephrased that comment.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Intel syntax is closer to the standard asm syntax on most architectures with the destination register coming first. AT&T syntax is actually based on PDP-11 assembly since that was the original platform for UNIX and the x86 port adapted the existing assembler instead of using the standard syntax.

@folkertdev folkertdev force-pushed the x86-asm-syntax-global-naked-asm branch from 8294047 to dcdb451 Compare July 8, 2025 23:08
@folkertdev folkertdev force-pushed the x86-asm-syntax-global-naked-asm branch from dcdb451 to 6fc5d4e Compare July 8, 2025 23:10
@Amanieu
Copy link
Member

Amanieu commented Jul 8, 2025

@bors r+

@bors
Copy link
Collaborator

bors commented Jul 8, 2025

📌 Commit 6fc5d4e has been approved by Amanieu

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

options(att_syntax) doesn't do anything for global_asm! and naked_asm!
5 participants