WIP: Decommission async-support

[Woyten]

Overview

I am trying to remove the async-support crate as it should no longer be required due to the merge of rust-lang/rust/pull/69033 into libcore.

Besides the async-support crate removal the PR contains some commits from my technical debt backlog.

Obstacles

The most recent nightlies are not shipped with our static code analysis tooling (rustfmt / clippy). The solution, however, is easy: Wait until they reappear in a newer nightly.

Questions / Ideas (Outdated)

Can someone explain why assembly is used at all? I am aware that certain operations like setting the stack pointer aren't possible without it. But the remaining code could be written in pure Rust. In fact, it has been written in pure Rust in the past.

As people care about reliability and certifiability, I propose to reduce the fraction of hard-to-review and possibly-breaking ASM code to a minimal amount possible.

[alistair23]

I'm all for this!

Unfortunately I can't comment about the ARM assembly (I just don't know). It seems strange that a register is deprecated.

If the assembly can be written in Rust I see no reason not to do that.

For the RISC-V assembly I guess the ecalls could be written in Rust, but as we are already in an assembly block it seems pretty straight forward to just do it all together. I assume the ARM assembly is the same.

[jrvanwhy]

Please elaborate on "the R7 register in ARM has been deprecated". That doesn't make sense to me.

The entry point cannot be written purely in Rust, although it can be external assembly rather than inline assembly. I was planning to (eventually) rework the entry point to look more like the entry point here: https://github.com/tock/design-explorations/blob/master/size_comparison/no_futures/src/entry_point.rs. That entry point has a much shorter assembly section. The one thing I would change from the size_comparison entry point is I would use .rt_header to convey data_flash_start and data_ram_start rather than EmptySymbol.

[jrvanwhy]

I think line 9 is well beyond 80 characters, please wrap.

[Woyten]

I can wrap the line but at least for me (I am using an IDE with line wrapping) it produces more harm than benefit. It's not even enforced by rustfmt, so I don't think it's an official standard or so.

[jrvanwhy]

Most Rust code wraps comments at 80 characters, and this repository is no different. rustfmt doesn't automatically wrap comments because reliably wrapping comments well is very difficult (see the examples at rust-lang/rustfmt#535). It is best to do it in your editor rather than with rustfmt, so you can catch mistakes.

Please wrap the comment at 80 characters.

[Woyten]

Please elaborate on "the R7 register in ARM has been deprecated". That doesn't make sense to me.

Maybe the word deprecated isn't correct in this case. However, I get the message error: <inline asm>:1:1: warning: inline asm clobber list contains reserved registers: R7

[Woyten]

The entry point cannot be written purely in Rust

Why is that so? In the past, the entry point was in pure Rust except for some stack pointer operations.

[jrvanwhy]

Maybe the word deprecated isn't correct in this case. However, I get the message error: <inline asm>:1:1: warning: inline asm clobber list contains reserved registers: R7

Ah, it looks like r7 is used for the frame pointer on Thumb: https://reviews.llvm.org/D49727. Because _start is a naked function, I don't think the clobbers actually need to be correct, so we can remove "r7" without changing anything else.

[jrvanwhy]

The entry point cannot be written purely in Rust

Why is that so? In the past, the entry point was in pure Rust except for some stack pointer operations.

I think the assembly in the entry point at https://github.com/tock/design-explorations/blob/master/size_comparison/no_futures/src/entry_point.rs is pretty minimal. I do the following in that assembly:

1. Verify that .start is in the correct location (lines 66-69). This is technically optional, but extremely useful. If done, it must be done in assembly, as it must be first and Rust code won't behave correctly at this point of the start sequence.
2. Call LowLevelDebug with a relocation failure if the relocation check fails (lines 70-74). If the relocation check fails, we definitely cannot run Rust code yet. Again, optional, but very useful, and if done at all this must be assembly.
3. Move the app break to make room for the stack (lines 79-81). This must be assembly because we don't have a working stack yet.
4. Set the stack pointer (line 83). This must be assembly because we don't have a working stack yet.
5. Call rust_start (line 86). This must be done manually because the only code we can have in a naked function is inline assembly.

Is there anything else you think can be Rust?

EDIT:
Oh yeah, there's also a yield loop at the end (lines 91-93). That loop serves double duty as the code that executes when main() returns and the code that executes after a relocation check failure.

[Woyten]

I don't think the clobbers actually need to be correct, so we can remove "r7" without changing anything else.

This helped. Thanks!

I meant to improve the r7 register fix, not the entire PR.

[jrvanwhy]

Looks good to me, modulo waiting for a working toolchain with rustfmt and clippy.

[alistair23]

What is still WIP here?

[Woyten]

What is still WIP here?

We need to wait for a nightly containing rustfmt and clippy.