Skip to content

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

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 5 commits into
base: master
Choose a base branch
from

Conversation

workingjubilee
Copy link
Member

@workingjubilee workingjubilee commented Jun 7, 2025

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
Copy link
Collaborator

rustbot commented Jun 7, 2025

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
Copy link
Collaborator

rustbot commented Jun 7, 2025

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 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
@folkertdev
Copy link
Contributor

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
Copy link
Member Author

workingjubilee commented Jun 7, 2025

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
Copy link
Collaborator

bors commented Jun 8, 2025

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants