Tracking Issue for asm_sym #93333
Comments
Amanieu
added
A-inline-assembly
|
Is this note from #72016 still accurate?
|
|
Yes it is. |
|
Is there any chance of splitting stabilisation of this so that |
|
@dylanede Interesting, that seems like a reasonable idea. |
|
That was suggested during the stabilization of asm, but rejected because:
|
IMO the way to do this is to require an Only downside I can think of is that it's a bit annoying that a HIR body containing a path to a
I would not want to disallow anything that works in paths within a function, seems like an artificial limitation when there is clearly an implementation strategy that works (i.e. the current one), and |
|
#94468 adds |
Implement sym operands for global_asm! Tracking issue: rust-lang#93333 This PR is pretty much a complete rewrite of `sym` operand support for inline assembly so that the same implementation can be shared by `asm!` and `global_asm!`. The main changes are: - At the AST level, `sym` is represented as a special `InlineAsmSym` AST node containing a path instead of an `Expr`. - At the HIR level, `sym` is split into `SymStatic` and `SymFn` depending on whether the path resolves to a static during AST lowering (defaults to `SynFn` if `get_early_res` fails). - `SymFn` is just an `AnonConst`. It runs through typeck and we just collect the resulting type at the end. An error is emitted if the type is not a `FnDef`. - `SymStatic` directly holds a path and the `DefId` of the `static` that it is pointing to. - The representation at the MIR level is mostly unchanged. There is a minor change to THIR where `SymFn` is a constant instead of an expression. - At the codegen level we need to apply the target's symbol mangling to the result of `tcx.symbol_name()` depending on the target. This is done by calling the LLVM name mangler, which handles all of the details. - On Mach-O, all symbols have a leading underscore. - On x86 Windows, different mangling is used for cdecl, stdcall, fastcall and vectorcall. - No mangling is needed on other platforms. r? `@nagisa` cc `@eddyb`
Implement sym operands for global_asm! Tracking issue: rust-lang#93333 This PR is pretty much a complete rewrite of `sym` operand support for inline assembly so that the same implementation can be shared by `asm!` and `global_asm!`. The main changes are: - At the AST level, `sym` is represented as a special `InlineAsmSym` AST node containing a path instead of an `Expr`. - At the HIR level, `sym` is split into `SymStatic` and `SymFn` depending on whether the path resolves to a static during AST lowering (defaults to `SynFn` if `get_early_res` fails). - `SymFn` is just an `AnonConst`. It runs through typeck and we just collect the resulting type at the end. An error is emitted if the type is not a `FnDef`. - `SymStatic` directly holds a path and the `DefId` of the `static` that it is pointing to. - The representation at the MIR level is mostly unchanged. There is a minor change to THIR where `SymFn` is a constant instead of an expression. - At the codegen level we need to apply the target's symbol mangling to the result of `tcx.symbol_name()` depending on the target. This is done by calling the LLVM name mangler, which handles all of the details. - On Mach-O, all symbols have a leading underscore. - On x86 Windows, different mangling is used for cdecl, stdcall, fastcall and vectorcall. - No mangling is needed on other platforms. r? ``@nagisa`` cc ``@eddyb``
Implement sym operands for global_asm! Tracking issue: rust-lang#93333 This PR is pretty much a complete rewrite of `sym` operand support for inline assembly so that the same implementation can be shared by `asm!` and `global_asm!`. The main changes are: - At the AST level, `sym` is represented as a special `InlineAsmSym` AST node containing a path instead of an `Expr`. - At the HIR level, `sym` is split into `SymStatic` and `SymFn` depending on whether the path resolves to a static during AST lowering (defaults to `SynFn` if `get_early_res` fails). - `SymFn` is just an `AnonConst`. It runs through typeck and we just collect the resulting type at the end. An error is emitted if the type is not a `FnDef`. - `SymStatic` directly holds a path and the `DefId` of the `static` that it is pointing to. - The representation at the MIR level is mostly unchanged. There is a minor change to THIR where `SymFn` is a constant instead of an expression. - At the codegen level we need to apply the target's symbol mangling to the result of `tcx.symbol_name()` depending on the target. This is done by calling the LLVM name mangler, which handles all of the details. - On Mach-O, all symbols have a leading underscore. - On x86 Windows, different mangling is used for cdecl, stdcall, fastcall and vectorcall. - No mangling is needed on other platforms. r? `@nagisa` cc `@eddyb`
Implement sym operands for global_asm! Tracking issue: rust-lang#93333 This PR is pretty much a complete rewrite of `sym` operand support for inline assembly so that the same implementation can be shared by `asm!` and `global_asm!`. The main changes are: - At the AST level, `sym` is represented as a special `InlineAsmSym` AST node containing a path instead of an `Expr`. - At the HIR level, `sym` is split into `SymStatic` and `SymFn` depending on whether the path resolves to a static during AST lowering (defaults to `SynFn` if `get_early_res` fails). - `SymFn` is just an `AnonConst`. It runs through typeck and we just collect the resulting type at the end. An error is emitted if the type is not a `FnDef`. - `SymStatic` directly holds a path and the `DefId` of the `static` that it is pointing to. - The representation at the MIR level is mostly unchanged. There is a minor change to THIR where `SymFn` is a constant instead of an expression. - At the codegen level we need to apply the target's symbol mangling to the result of `tcx.symbol_name()` depending on the target. This is done by calling the LLVM name mangler, which handles all of the details. - On Mach-O, all symbols have a leading underscore. - On x86 Windows, different mangling is used for cdecl, stdcall, fastcall and vectorcall. - No mangling is needed on other platforms. r? `@nagisa` cc `@eddyb`
|
Now that #94468 has landed, is all that's left to make a stabilization report? |
Stabilization reportThis is a stabilization request for the DescriptionThis feature adds a
Exampleextern "C" fn add(x: i32, y: i32) -> i32 {
x + y
}
// AArch64
let result: i32;
asm!(
"call {}",
sym add,
in("x0") 1,
in("x1") 2,
lateout("x0") result,
clobber_abi("C"),
);
assert_eq!(result, 3);TestsThis feature is tested in:
|
Implement sym operands for global_asm! Tracking issue: rust-lang#93333 This PR is pretty much a complete rewrite of `sym` operand support for inline assembly so that the same implementation can be shared by `asm!` and `global_asm!`. The main changes are: - At the AST level, `sym` is represented as a special `InlineAsmSym` AST node containing a path instead of an `Expr`. - At the HIR level, `sym` is split into `SymStatic` and `SymFn` depending on whether the path resolves to a static during AST lowering (defaults to `SynFn` if `get_early_res` fails). - `SymFn` is just an `AnonConst`. It runs through typeck and we just collect the resulting type at the end. An error is emitted if the type is not a `FnDef`. - `SymStatic` directly holds a path and the `DefId` of the `static` that it is pointing to. - The representation at the MIR level is mostly unchanged. There is a minor change to THIR where `SymFn` is a constant instead of an expression. - At the codegen level we need to apply the target's symbol mangling to the result of `tcx.symbol_name()` depending on the target. This is done by calling the LLVM name mangler, which handles all of the details. - On Mach-O, all symbols have a leading underscore. - On x86 Windows, different mangling is used for cdecl, stdcall, fastcall and vectorcall. - No mangling is needed on other platforms. r? `@nagisa` cc `@eddyb`
|
For those you'd have to use a bunch of cfg the same as C would (apparently) use a bunch of macros. and the cfg would have to go by a cargo feature or other expression that says what the linking mode will be. |
|
Would it be possible to expose the code model and relocation model via |
|
@Amanieu wrote:
It's inherently architecture-specific; it doesn't necessarily have to be OS-specific. |
joshtriplett
added
the
S-tracking-ready-to-stabilize
|
@rfcbot concern rust-reference Is there a PR adding this to the rust reference? |
|
@rfcbot reviewed |
|
No, but the addition is pretty small. It's basically a revert of this. |
|
@Amanieu great! Can you open a PR with that revert? |
|
@rfcbot resolve rust-reference |
rfcbot
added
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
rfcbot
added
finished-final-comment-period
|
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
|
It sounds like all that is left is for an actual stabilization PR to be submitted? |
|
Stabilize asm_sym Tracking issue rust-lang#93333 Reference PR: rust-lang/reference#1270
Stabilize asm_sym Tracking issue rust-lang#93333 Reference PR: rust-lang/reference#1270
|
Shouldn't this issue be closed since the feature was stabilized? |
Uh oh!
There was an error while loading. Please reload this page.
The feature gate for the issue is
#![feature(asm_sym)].Summary
This feature adds a
sym <path>operand type toasm!andglobal_asm!.<path>must refer to afnorstatic.<path>is allowed to point to a#[thread_local]static, in which case the asm code can combine the symbol with relocations (e.g.@plt,@TPOFF) to read from thread-local data.Status
Blocked on support forsyminglobal_asm!.The text was updated successfully, but these errors were encountered: