Skip to content
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

Update clobber to match ARM ARM #426

Closed
wants to merge 1 commit into from
Closed

Update clobber to match ARM ARM #426

wants to merge 1 commit into from

Conversation

ppannuto
Copy link
Member

@ppannuto ppannuto commented Aug 8, 2022

I just learned about this asm! feature, which prompted me to look at whether we were using it.

Not sure if some of the others were options when #381 was written, but strictly speaking arm cores are defined to follow the AAPCS on exception entry/exit. In practice, I think C and aapcs (and the others here) are just aliases that do the same thing. Nonetheless, just in case, we should probably put the 'most correct' name here.

Relevant doc: https://doc.rust-lang.org/nightly/reference/inline-assembly.html#abi-clobbers
image

I just learned about this `asm!` feature, which prompted me to look at whether we were using it.

Not sure if some of the others were options when #381 was written, but strictly speaking arm cores are defined to follow the `AAPCS` on exception entry/exit. In practice, I _think_ `C` and `aapcs` (and the others here) are just aliases that do the same thing. Nonetheless, just in case, we should probably put the 'most correct' name here.

Relevant doc: https://doc.rust-lang.org/nightly/reference/inline-assembly.html#abi-clobbers
@alistair23
Copy link
Collaborator

Looking at that it seems like "C" is the correct name to use, as we can use it on all platforms. Why do you think aapcs is the correct name?

@ppannuto
Copy link
Member Author

ppannuto commented Aug 9, 2022

Strictly speaking, ARM cores are defined to adhere to the AAPCS on exception entry and exit. There also exists a separate specification, the C Library ABI. In practice (and for obvious reasons), these both resolve to the same base ARM ABI.

Will this ever matter? Not in this century I can't imagine, the C and AAPCS ABIs will likely always be the same. But it struck me as odd to see C there when I happened to look at this earlier, so I figured we should update to match the letter of the law. Not a critical thing (see that branch name 😆).

[Plus, what a shame to have a lingering C hanging around in the Rust libtock on the Rust tock -- especially if it shouldn't be there anyway!]

@jrvanwhy
Copy link
Collaborator

jrvanwhy commented Aug 9, 2022

There is more to this than just exception entry and exit. Yield may invoke an upcall, which has its own ABI. Currently, libtock-rs is hardcoded to use the C ABI for upcalls.

That ABI should match the ABI used by Yield's asm! -- except it is in libtock_platform, which is platform-independent code! I'm not sure we want to switch the ABI specification for different architectures.

Also IDK if we want to touch libtock_unittest. Ostensibly libtock_unittest should be cross platform too and should use AAPCS on ARM, but it's not an easy change to make and we don't have an easy way to test it.

Strictly speaking, ARM cores are defined to adhere to the AAPCS on exception entry and exit.

What exactly does this mean? Does the hardware store callee-saved registers for us? I thought the Tock kernel saves them in the grant region.

@ppannuto
Copy link
Member Author

ppannuto commented Aug 9, 2022

This looks like it touches more things than I realized, and given that the two are almost certainly identical for the forseeable future, leaving this as C makes sense.


What exactly does this mean? Does the hardware store callee-saved registers for us?

The hardware stores the caller-saved registers for us. Conceptually, ARM exception entry is a function call (adhering to the AAPCS) injected by the hardware at the point of the exception. As the hardware is the thing 'calling' the function, it has to do all the caller-saving responsibilities.

I thought the Tock kernel saves them in the grant region.

Yes, callee-saved registers the kernel stores in the CortexMStoredState.regs, which is part of the ProcessStandard struct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants