Withdraw the claim `extern "C-cmse-nonsecure-*"` always matches `extern "C"` by workingjubilee · Pull Request #142146 · rust-lang/rust (original) (raw)

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 andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation15 Commits7 Checks10 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

We currently claim that extern "C-cmse-nonsecure-*" ABIs will always match extern "C", but that seems... optimistic when one considers that extern "C" is ambiguous enough to be redefined in ways we may not want the Cortex M Security Extensions ABIs to mirror. If some configuration, feature, or other platform quirk that applied to Arm CPUs with CMSE would modify the extern "C" ABI, it does not seem like we should guarantee that also applies to the extern "cmse-nonsecure-*" ABIs. Anything involving target modifiers that might affect register availability or usage could make us liars if, for instance, clang decides those apply to normal C functions but not ones with the CMSE attributes, but we still want to have interop with the C compiler.

We simply do not control enough of the factors involved to both force these ABIs to match and still provide useful interop, so we shouldn't implicitly promise they do. We should leave this judgement call to the decisions of platform experts who can afford to keep up with the latest news from Cambridge, instead of enshrining today's hopeful guess forever in Rust's permitted ABIs.

It's a bit weird anyways.

The attributes are __attribute__((cmse_nonsecure_call)) and __attribute__((cmse_nonsecure_entry)), so the obvious choice is extern "cmse-nonsecure-call" and extern "cmse-nonsecure-entry".
We do not prefix any other ABI that reflects (or even is) a C ABI with "C-", with the exception of the Rust-defined extern "C-unwind", e.g. we do not have extern "C-aapcs" or extern "C-sysv64".

Tracking issues:

r? @compiler-errors

rustbot has assigned @compiler-errors.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

HIR ty lowering was modified

cc @fmease

These commits modify compiler targets.
(See the Target Tier Policy.)

Some changes occurred in diagnostic error codes

cc @GuillaumeGomez

This PR changes a file inside tests/crashes. If a crash was fixed, please move into the corresponding ui subdir and add 'Fixes #' to the PR description to autoclose the issue upon merge.

rustbot added 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

Jun 7, 2025

This was referenced

Jun 7, 2025

Fair enough.

AAPCS is used as a base, but https://arm-software.github.io/acle/cmse/cmse.html describes some of deviations from it (e.g. secure can't assume that unsecure properly sign/zero extended integers). Also actually we implement the LLVM interpretation of the specification (which just disallows using the stack for argument passing altogether).

Yeah, there was speculation in the original thread, as it led to the suggestion of "C-cmse-nonsecure-*", that there might be "interop with other calling conventions". But the ABI is so constrained, its arity topping out at ~4, due to only a few registers and no stack, that I can't see any real room for improvement there. Nor difference, really.

Choose a reason for hiding this comment

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

Should we rename the feature gate too? r=me after that or sufficient justification for why that's not doable (which I'm somewhat skeptical of since we're already breaking nightly users of the feature by renaming the ABI name).

rustbot added S-waiting-on-author

Status: This is awaiting some action (such as code changes or more information) from the author.

and removed S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

labels

Jun 11, 2025

Right. Rebased this over the 10 different PRs that are touching ABI-related code. Will push actual update soon.

📌 Commit b769c62 has been approved by compiler-errors

It is now in the queue for this repository.

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-author

Status: This is awaiting some action (such as code changes or more information) from the author.

labels

Jun 24, 2025

workingjubilee added a commit to workingjubilee/rustc that referenced this pull request

Jun 25, 2025

…secure-abis-always-match-c, r=compiler-errors

Withdraw the claim extern "C-cmse-nonsecure-*" always matches extern "C"

It's a bit weird anyways.

The attributes are __attribute__((cmse_nonsecure_call)) and __attribute__((cmse_nonsecure_entry)), so the obvious choice is extern "cmse-nonsecure-call" and extern "cmse-nonsecure-entry".
We do not prefix any other ABI that reflects (or even is) a C ABI with "C-", with the exception of the Rust-defined extern "C-unwind", e.g. we do not have extern "C-aapcs" or extern "C-sysv64".

Tracking issues:

workingjubilee added a commit to workingjubilee/rustc that referenced this pull request

Jun 25, 2025

…secure-abis-always-match-c, r=compiler-errors

Withdraw the claim extern "C-cmse-nonsecure-*" always matches extern "C"

It's a bit weird anyways.

The attributes are __attribute__((cmse_nonsecure_call)) and __attribute__((cmse_nonsecure_entry)), so the obvious choice is extern "cmse-nonsecure-call" and extern "cmse-nonsecure-entry".
We do not prefix any other ABI that reflects (or even is) a C ABI with "C-", with the exception of the Rust-defined extern "C-unwind", e.g. we do not have extern "C-aapcs" or extern "C-sysv64".

Tracking issues:

bors added S-waiting-on-author

Status: This is awaiting some action (such as code changes or more information) from the author.

and removed S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

labels

Jun 25, 2025

last rebase. I think. pray.
@bors r=compiler-errors

📌 Commit 3beed38 has been approved by compiler-errors

It is now in the queue for this repository.

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-author

Status: This is awaiting some action (such as code changes or more information) from the author.

labels

Jun 25, 2025

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request

Jun 25, 2025

…secure-abis-always-match-c, r=compiler-errors

Withdraw the claim extern "C-cmse-nonsecure-*" always matches extern "C"

It's a bit weird anyways.

The attributes are __attribute__((cmse_nonsecure_call)) and __attribute__((cmse_nonsecure_entry)), so the obvious choice is extern "cmse-nonsecure-call" and extern "cmse-nonsecure-entry".
We do not prefix any other ABI that reflects (or even is) a C ABI with "C-", with the exception of the Rust-defined extern "C-unwind", e.g. we do not have extern "C-aapcs" or extern "C-sysv64".

Tracking issues:

bors added a commit that referenced this pull request

Jun 25, 2025

Rollup of 7 pull requests

Successful merges:

#142146 (Withdraw the claim extern "C-cmse-nonsecure-*" always matches extern "C")
#142200 (tests/ui: A New Order [8/N])
#142724 (Add runtime check to avoid overwrite arg in Diag)
#142809 (Add PrintTAFn flag for targeted type analysis printing)
#142976 (Check CoerceUnsized impl validity before coercing)
#142992 (Convert some ABI tests to use extern "rust-invalid")
#143000 (Make Sub, Mul, Div and Rem const_traits)

r? @ghost @rustbot modify labels: rollup

rust-timer added a commit that referenced this pull request

Jun 26, 2025

Rollup merge of #142146 - workingjubilee:doubt-that-cmse-nonsecure-abis-always-match-c, r=compiler-errors

Withdraw the claim extern "C-cmse-nonsecure-*" always matches extern "C"

It's a bit weird anyways.

The attributes are __attribute__((cmse_nonsecure_call)) and __attribute__((cmse_nonsecure_entry)), so the obvious choice is extern "cmse-nonsecure-call" and extern "cmse-nonsecure-entry".
We do not prefix any other ABI that reflects (or even is) a C ABI with "C-", with the exception of the Rust-defined extern "C-unwind", e.g. we do not have extern "C-aapcs" or extern "C-sysv64".

Tracking issues:

github-actions bot pushed a commit to rust-lang/rustc-dev-guide that referenced this pull request

Jun 26, 2025

Withdraw the claim extern "C-cmse-nonsecure-*" always matches extern "C" by workingjubilee · Pull Request #142146 · rust-lang/rust (original) (raw)

Conversation

Choose a reason for hiding this comment

Labels

Withdraw the claim `extern "C-cmse-nonsecure-*"` always matches `extern "C"` by workingjubilee · Pull Request #142146 · rust-lang/rust (original) (raw)