Miri Experiment

[bjoernQ]

Thank you for your contribution!

We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:

Submission Checklist 📝

• I have updated existing examples or added new ones (if applicable).
• I have used cargo xtask fmt-packages command to ensure that all changed code is formatted correctly.
• My changes were added to the CHANGELOG.md in the proper section.
• I have added necessary changes to user code to the Migration Guide.
• My changes are in accordance to the esp-rs developer guidelines

Extra:

• I have read the CONTRIBUTING.md guide and followed its instructions.

Pull Request Details 📖

Description

This isn't intended to get merged (especially not as is)! It's just for exploring and discussing if and how we could make use of MIRI

• apparently unsafe { &*Self::PTR } is not ok for register blocks ( Const validation rejects references that might be dangling (but could actually be valid at run-time) rust-lang/rust#63197 (comment) ) - the first commit here is just to not already fail during compilation
• We don't have MIRI for Xtensa - so just using our RV targets here
• I admit that single test added here is not useful - I can imagine MIRI could make sense to check some other things, however. Probably we would have to make use of #[cfg(miri)] to make interesting functions available

Testing

n/a

[bugadani]

Wait, this compiles? 👀

[MabezDev]

This is interesting! Thanks for looking in to this!

I'm curious if we can just run all (or a subset) of our HIL tests with miri enabled? That would feel a bit more useful than writing seperate miri specific tests, I think. I've never actually tested any of my projects with MIRI though, so I'm not sure how it's typically used.

[bjoernQ]

I thought about how we could test usual driver code - one thing that might be possible would be to have a forked svd2rust which produces mock-PACs which Miri won't hate (it definitely hates writing / reading to / from random addresses) - and also our drivers expect something to happen when we write to the hw-registers

I think that could work - I am just not very sure if it's a good deal in terms of effort vs benefit - but would definitely be fun to explore

[bjoernQ]

Apparently the idea of mocking register access is not new: https://crates.io/crates/regmock-rs

[MabezDev]

This was a nice experiment!

I think we have two options here. We keep this as it is, merge it and we find a "use" (some nicer test cases) for this, or we drop this until we have a test case. What do you think?

My main interest is if we can test or catch things like #3555 which we wouldn't catch even with HIL (unless we get lucky or run millions of iterations).

[bjoernQ]

I think there are good use cases for something like this but there is not much use in keeping this PR open (or merge it).

It will stay with us under the closed-PRs so we can easily come back to this once we have something nice to check.
(Especially I was interested in checking things where we are unsure about the soundness / UB - using it to generally run host-tests is a nice side effect but the PACs will make Miri very, very mad)

TL;DR will close this, but it will still be here for further reference