Skip to content

CMSE calling conventions #3884

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.

Sign up for GitHub

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
folkertdev wants to merge 7 commits into
base: master
Choose a base branch
from
+341 −0
Open

CMSE calling conventions #3884

Changes from 1 commit
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
21f5b58
RFC for CMSE calling conventions
folkertdev Sep 24, 2025
36a713b
clarify the targets cmse is available on
folkertdev Nov 29, 2025
8b32c63
Apply suggestions from code review
folkertdev Nov 30, 2025
44c775b
clarify calling convention conversions
folkertdev Jan 13, 2026
09460e6
Update text/0000-cmse-calling-conventions.md
folkertdev Jan 13, 2026
448d00e
clarify when 64-bit types qualify to be returned
folkertdev Jan 25, 2026
ae12919
more clarification on when arguments fit
folkertdev Jan 28, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 10 additions & 1 deletion text/0000-cmse-calling-conventions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -95,7 +95,16 @@ type T4 = extern "cmse-nonsecure-call" fn() -> i128;
type T5 = extern "cmse-nonsecure-call" fn(_: i64, _: i64) -> WrappedI64;
```

An error is emitted when the program contains a signature that violates the calling convention's constraints:
The arguments fit if:

- the sum of their sizes, each rounded up to the next multiple of 4, is 16 bytes or less
Copy link
Member

@RalfJung RalfJung Jan 28, 2026

Choose a reason for hiding this comment

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

So, a single argument of type (i32, (i8, i16), i64) is allowed?

That's... very strange and not at all what I expected. In the end I don't care that strongly as long as it is clearly specified, but implementation-wise this seems like it could become quite messy.

Is this our ABI to define or is it a standard ABI we have to follow? If it is the latter, allowing repr(Rust) types (this includes tuples) might be a mistake -- it would be the first time we make any kind of ABI guarantees for them.

Copy link
Author

@folkertdev folkertdev Jan 28, 2026

Choose a reason for hiding this comment

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

It is really just aapcs, so the 32-bit arm C calling convention. It already lints on passing repr(Rust) types, I'd be fine with actually disallowing them though. This is meant to be an FFI boundary, the user is meant to think about the constraints.

Copy link
Member

@RalfJung RalfJung Jan 28, 2026

Choose a reason for hiding this comment

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

The thing is that for normal aapcs, if we change repr(Rust) things won't fail to build. They might "just" stop working properly if you ignored the lints. This RFC turns things into a hard error, which typically has a different par for the lang team. But this feels worth explicitly calling out as an open question to them to get their vibes on it. After all, changing the size of a type can already lead to compilation failures due to repr(transparent).


A return value fits if either:

- its size is 4 bytes or less
- it is an (optionally transparently wrapped) `i64`, `u64` or `f64`

When the arguments or return type do not fit in the available registers, an error is emitted:

```
error[E0798]: arguments for `"cmse-nonsecure-entry"` function too large to pass via registers
Expand Down