Add a pre_init function to be called at the start of the reset handler

[jcsoo]

Implements #17

I kept the implementation as close to DEFAULT_HANDLER as possible. Unsure whether the pre_init function should be unsafe or not.

[japaric]

Thanks for the PR @jcsoo.

Unfortunately it can't be accepted as it is because this crate must compile on beta / stable by default. However, this could land behind an opt-in feature.

#51 is another take on this problem that uses the .pre_init_array support in the r0 crate. One of the biggest questions about this feature is how to deal with peripheral singletons: if you take the peripherals in pre-init then you can't use them in main; and if you take the peripherals in pre-init then you have to use a static to pass them to main but that makes them globally visible, which is bad, and imposes synchronazation overhead (and maybe Option.unwraping).

Look at my latest comment in #51 for my current thoughts on this issue.

And yes pre_init functions need to be marked unsafe because accessing a static variable from them is undefined behavior (they are not initialized at that point).

[jcsoo]

Thanks for the response. I did this initial pull request against 0.4.0 because I haven't updated my code to 0.5.0 yet, but would it make sense for me to rebase it against the current version, gated against an opt-in feature?

I see now how the uninitialized statics require the pre_init function to be unsafe.

Regarding things like peripheral singletons, wouldn't that be the concern of the consuming crate? I can see how a crate using strict RAII at the peripheral level wouldn't simply be able to release the singleton, but crates using a different peripheral access philosophy (or simply using volatile access as is used for FPU initialization) wouldn't necessarily have that issue.

Would a better approach be to make __RESET_VECTOR a weak symbol and override at that level?

[japaric]

would it make sense for me to rebase it against the current version, gated against an opt-in feature?

I'd prefer not to add Cargo features that require nightly to enable. I think it's feasible to implement this feature without unstable features though.

Regarding things like peripheral singletons, wouldn't that be the concern of the consuming crate?

Yes, that's what I said in the other thread. That issue can solved in a downstream crate.

Would a better approach be to make __RESET_VECTOR a weak symbol and override at that level?

I think that's too dangerous. The user may omit the initialization of static variables causing UB in every function that uses static variables.

[yodaldevoid]

@jcsoo Is there a possibility you can update this in the near future so that it might be pulled in?

[korken89]

Hi @japaric / @jcsoo, what is the status of this PR / similar feature? I am writing a bootloader in Rust, and I would need to do checks before anything else runs to jump to user code.
If there is something I can help with, give me a ping and I can take over this PR to move it forward.

The support for running some "pre init" code is crucial to many embedded programs.

[japaric]

Thanks for the original PR, @jcsoo. I'm going to close this in favor of #81 which has an implementation that works on stable.