-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Tracking Issue for abi_custom
#140829
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
Labels
A-ABI
Area: Concerning the application binary interface (ABI)
A-inline-assembly
Area: Inline assembly (`asm!(…)`)
A-naked
Area: `#[naked]`, prologue and epilogue-free, functions, https://git.io/vAzzS
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
T-lang
Relevant to the language team
Comments
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this issue
Jun 12, 2025
add `extern "custom"` functions tracking issue: rust-lang#140829 previous discussion: rust-lang#140566 In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly. The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention. At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this. r? `@traviscross` cc `@tgross35`
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this issue
Jun 12, 2025
add `extern "custom"` functions tracking issue: rust-lang#140829 previous discussion: rust-lang#140566 In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly. The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention. At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this. r? ``@traviscross`` cc ``@tgross35``
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Jun 12, 2025
add `extern "custom"` functions tracking issue: rust-lang#140829 previous discussion: rust-lang#140566 In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly. The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention. At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this. r? ```@traviscross``` cc ```@tgross35```
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Jun 12, 2025
add `extern "custom"` functions tracking issue: rust-lang#140829 previous discussion: rust-lang#140566 In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly. The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention. At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this. r? ````@traviscross```` cc ````@tgross35````
bors
added a commit
that referenced
this issue
Jun 12, 2025
add `extern "custom"` functions tracking issue: #140829 previous discussion: #140566 In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly. The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention. At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this. r? `@traviscross` cc `@tgross35` try-job: x86_64-apple-2
bors
added a commit
that referenced
this issue
Jun 12, 2025
add `extern "custom"` functions tracking issue: #140829 previous discussion: #140566 In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly. The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention. At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this. r? `@traviscross` cc `@tgross35` try-job: x86_64-apple-2
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-ABI
Area: Concerning the application binary interface (ABI)
A-inline-assembly
Area: Inline assembly (`asm!(…)`)
A-naked
Area: `#[naked]`, prologue and epilogue-free, functions, https://git.io/vAzzS
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
T-lang
Relevant to the language team
The feature gate for the issue is
#![feature(abi_custom)]
.The goal of the
"custom"
ABI is to define functions that use a custom calling convention that rust does not natively know about.Background
One of the uses of naked functions is to implement custom calling conventions. We have some code in
compiler-builtins
like this:The ABI needs to be specified, so extern "C" is used. However, this is misleading as the function does not actually use the C calling convention.
Correct ABI would be considered part of the preconditions for this function and it would only be callable inside an unsafe block, but Rust has no way to call the function correctly so it seems like we should prevent this.
Design
The
"custom"
ABI can only be used with#[unsafe(naked)]
function declarations, and functions with this ABI cannot be called with a standard rust call expression.It is also possible to link to an
extern "custom"
function:The only way to execute an
extern "custom"
is to use inline assembly for the call:An
extern "custom¨
function cannot have any parameters or a return type. The types would be meaningless, and can easily go out of date. The function's documentation should describe how inline assembly can call the function: how arguments are passed and how a value is returned.An
extern "custom"
functions is alwaysunsafe
, mostly as a nudge for writing a# Safety
comment on their definition:extern "custom"
function declarations must use theunsafe
keywordunsafe extern "custom" { /* ... */ }
block, thesafe
keyword cannot be usedAbout tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.
Steps
extern "custom"
functions #140770Unresolved Questions
None
History
extern "unspecified"
for naked functions with arbitrary ABI #140566extern "custom"
functions #140770@rustbot label +T-lang +A-inline-assembly
The text was updated successfully, but these errors were encountered: