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

workingjubilee · 2025-06-07T07:10:50Z

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:

rustbot · 2025-06-07T07:10:56Z

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

rustbot · 2025-06-07T07:10:57Z

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.

folkertdev · 2025-06-07T11:11:35Z

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).

workingjubilee · 2025-06-07T16:57:49Z

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.

bors · 2025-06-08T03:05:54Z

☔ The latest upstream changes (presumably #142181) made this pull request unmergeable. Please resolve the merge conflicts.

bors · 2025-06-09T09:26:18Z

☔ The latest upstream changes (presumably #141435) made this pull request unmergeable. Please resolve the merge conflicts.

bors · 2025-06-10T21:47:14Z

☔ The latest upstream changes (presumably #142299) made this pull request unmergeable. Please resolve the merge conflicts.

compiler-errors

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).

compiler-errors · 2025-06-11T23:23:24Z

@rustbot author

workingjubilee · 2025-06-24T19:34:21Z

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

workingjubilee · 2025-06-24T22:51:59Z

@bors r=compiler-errors

bors · 2025-06-24T22:52:02Z

📌 Commit b769c62 has been approved by compiler-errors

It is now in the queue for this repository.

…secure-abis-always-match-c, r=compiler-errors Withdraw the claim `extern "C-cmse-nonsecure-*"` always matches `extern "C"` 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: - rust-lang#75835 - rust-lang#81391

workingjubilee · 2025-06-25T08:38:37Z

@bors r-

workingjubilee · 2025-06-25T09:32:41Z

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

bors · 2025-06-25T09:32:43Z

📌 Commit 3beed38 has been approved by compiler-errors

It is now in the queue for this repository.

…secure-abis-always-match-c, r=compiler-errors Withdraw the claim `extern "C-cmse-nonsecure-*"` always matches `extern "C"` 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: - rust-lang#75835 - rust-lang#81391

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

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"` 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: - #75835 - #81391

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

rustbot assigned compiler-errors Jun 7, 2025

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

Tracking Issue for the extern "C-cmse-nonsecure-entry" ABI #75835

Open

Tracking Issue for the extern "C-cmse-nonsecure-call" ABI #81391

Open

workingjubilee force-pushed the doubt-that-cmse-nonsecure-abis-always-match-c branch from 0ac788f to a8346e9 Compare June 8, 2025 04:32

workingjubilee force-pushed the doubt-that-cmse-nonsecure-abis-always-match-c branch from a8346e9 to 78bd02d Compare June 9, 2025 18:22

compiler-errors approved these changes Jun 11, 2025

View reviewed changes

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

workingjubilee force-pushed the doubt-that-cmse-nonsecure-abis-always-match-c branch from 78bd02d to 1bc022e Compare June 24, 2025 19:22

workingjubilee force-pushed the doubt-that-cmse-nonsecure-abis-always-match-c branch 3 times, most recently from 4e5b1b9 to b769c62 Compare June 24, 2025 20:48

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 mentioned this pull request Jun 25, 2025

Rollup of 15 pull requests #142995

Closed

workingjubilee mentioned this pull request Jun 25, 2025

Rollup of 2 pull requests #142996

Closed

workingjubilee added 7 commits June 25, 2025 00:52

compiler: Trim the misleading C from ExternAbi::CCmse*

35deb5b

compiler: remove misleading 'c' from abi_c_cmse_nonsecure_call feature

4bdf1c5

compiler: Trim the misleading C of C-cmse from errors

383d761

tests: s/C-cmse/cmse/

1400e2d

tests: bless s/C-cmse/cmse/

02a00df

move unstable book page and account for it

9cfee73

unstable-book: Update cmse feature descriptions

3beed38

workingjubilee force-pushed the doubt-that-cmse-nonsecure-abis-always-match-c branch from b769c62 to 3beed38 Compare June 25, 2025 07:53

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

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 mentioned this pull request Jun 25, 2025

Rollup of 8 pull requests #143012

Closed

jdonszelmann mentioned this pull request Jun 25, 2025

Rollup of 7 pull requests #143026

Merged

bors merged commit 8825997 into rust-lang:master Jun 26, 2025
10 checks passed

rustbot added this to the 1.90.0 milestone Jun 26, 2025

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

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

Uh oh!

Conversation

workingjubilee commented Jun 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jun 7, 2025

Uh oh!

rustbot commented Jun 7, 2025

Uh oh!

folkertdev commented Jun 7, 2025

Uh oh!

workingjubilee commented Jun 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bors commented Jun 8, 2025

Uh oh!

bors commented Jun 9, 2025

Uh oh!

bors commented Jun 10, 2025

Uh oh!

compiler-errors left a comment

Choose a reason for hiding this comment

Uh oh!

compiler-errors commented Jun 11, 2025

Uh oh!

workingjubilee commented Jun 24, 2025

Uh oh!

workingjubilee commented Jun 24, 2025

Uh oh!

bors commented Jun 24, 2025

Uh oh!

workingjubilee commented Jun 25, 2025

Uh oh!

workingjubilee commented Jun 25, 2025

Uh oh!

bors commented Jun 25, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

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

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

workingjubilee commented Jun 7, 2025 •

edited

Loading

workingjubilee commented Jun 7, 2025 •

edited

Loading