11:04 <jannic[m]> <dirbaio[m]> "how does that work, and could..." <- The startup process in std applications is nicely explained in https://os.phil-opp.com/freestanding-rust-binary/. Not sure if everything in that article is still up to date, but I don't think the general approach has changed in the meantime.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/xyZTvgUEslVxDoeDZdQDQeWo>)

11:08 <jannic[m]> This is still using the linker script and the asm.S from cortex-m-rt.

11:09 <adamgreig[m]> I think in principle it should be an extern C main but it probably doesn't make much odds here

11:09 <adamgreig[m]> (also c-m-rt doesn't have asm.S any more, it's a global_asm!() call, but same deal)

11:10 <adamgreig[m]> But I guess the question is whether we could co-opt Rust's knowledge of std main() to allow an embedded program using cmrt to just write fn main()->! and not need no_main nor the macro

11:11 <adamgreig[m]> Which would be cool...

14:10 <JamesMunns[m]> I think you could `extern "rust"` it if cmrt provides the start? It's not checked then though, I think it's possible to declare `fn main () -> !;` in one place and define it as `fn main() -> () { ... }` in another

14:43 <thejpster[m]> OK, clearly we need to work on our documentation. the entry macro does several things:

14:44 <thejpster[m]> 1. it ensures *your* main function has the right type. If you have a no-mangle `pub fn extern "C" main(arguments: &[u8])` you will have a bad time (because you will not get that argument, and you are not supposed to return).

14:45 <thejpster[m]> 2. It hides the 'real main' function and your main function so that you cannot re-enter main from your program.

14:45 <thejpster[m]> 3. It remaps `static mut` variables to be `&mut` refs to those statics, which are safe to use. This is because 2 ensures you can't re-enter your main function and thus those references are indeed exclusive.

14:46 <thejpster[m]> You can't use the start lang-item becuase it's not stable. And so a macro was invented. This is mostly covered in the embedonomicon, but that talks about it in abstract terms and doesn't refer to the entry macro specifically.

14:48 <thejpster[m]> Providing your own fn extern "C" main() is probably the preferred approach if you are using CRT1 to boot your chip. cortex-m-rt eschews crt1, I guess in the name of "it's better if people don't need gcc", but some people are using things that are not cortex-m and the start-up is a PITA and they want their gcc to do the hard work for them. So we should probably have an example for that. My LEON3 demo does this, for example

14:48 <thejpster[m]> (github.com/ferrous-systems/sparc-experiments).

14:51 <thejpster[m]> jannic: I wouldn't rely on being able to call an extern "Rust" function from the asm start-up code. The Rust ABI is not specified and who knows what assumptions the compiler makes about the caller pushing things. You need to make your main extern "C".

14:58 <jannic[m]> That's true. While there aren't so many useful calling conventions for a function that doesn't take arguments and never returns, it's obviously better to use the right calling conventions from the start.

15:36 <adamgreig[m]> If we taught Rust how to start cmrt, you could conceivably have fn main() just like you for hosted platforms, with rust abi, since the rust provided ASM would call it correctly

15:37 <adamgreig[m]> It's not like we're eschewing "crt1" though, we'd need to link in some specific startup code from arm or cmsis or something if we didn't provide our own, not just something from gcc

15:38 <adamgreig[m]> If we dropped the static mut transform then I don't think we'd need the non-reentrancy either which might be less surprising to people, but it's what we have at the moment

15:40 <jannic[m]> Sometimes it's convenient to know that some code runs exactly once, and first after boot, to do some initialization that would be unsound if done later. Not an unsolvable problem, of course.

15:48 <adamgreig[m]> Yea, it doesn't really cost us anything to keep it I don't think, beyond a tiny bit of documentation complexity