riscv-rt: Leave __pre_init under a feature gate
#282
Conversation
romancardenas
force-pushed
the
pre-init
branch
5 times, most recently
from
69b56a2 to
f7c74f8
Compare
| /// | ||
| /// # fn main() {} | ||
| /// ``` | ||
| #[deprecated(note = "Use global_asm! to define the __pre_init function instead")] |
There was a problem hiding this comment.
Will we be removing this in the next (or another future) point release?
I wasn't aware that using Rust code before RAM init was unsound. Is this true even for code that only uses the stack?
There was a problem hiding this comment.
I'm not sure about how Rust's ABI can break something. I guess that, if you do not use static variables, it should be fine
There was a problem hiding this comment.
From cortex-m documentation:
A
#[pre_init]macro is also provided to run a function before RAM initialisation, but its use is deprecated as it is not defined behaviour to execute Rust code before initialisation. It is still possible to create a custompre_initfunction using assembly.
There was a problem hiding this comment.
We also discussed this on Monday's meeting. I think the consensus was that there were too many preconditions + invariants to justify keeping a pre_init implementation in Rust.
I think it may still be helpful to point to the feature-gated __pre_init function in the riscv-rt docs as an example for users that would want to implement their own. Maybe in the place currently held by #[pre_init] or above the _pre_init_trap?
Still working on #247
The idea is to remove
__pre_initfrom the defaultriscv-rtcrate. If users want it, they must enable thepre-initfeature.If enabled, no default
__pre_initsymbol is provided, as we assume that users will develop their routine.Additionally, the
riscv_rt::pre_initattribute macro is now marked as deprecated, as running Rust code before RAM initialization is unsound, and assembly code is preferred.