static_buf!(): Remove StaticUninitializedBuffer and UninitializedBuffer in favor of MaybeUninit, update component conventions to match
#3239
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bradjc
previously approved these changes
Sep 21, 2022
2 tasks
static_buf!(): Remove StaticUninitializedBuffer and UninitializedBuffer in favor of MaybeUninitstatic_buf!(): Remove StaticUninitializedBuffer and UninitializedBuffer in favor of MaybeUninit, update component conventions to match
bradjc
previously approved these changes
Sep 22, 2022
2 tasks
4a70cf7 to
ab89f67
Compare
hudson-ayers
commented
Sep 22, 2022
| let hmac = &perf.hmac; | ||
|
|
||
| let callback = unsafe { static_init_test_cb() }; | ||
| let callback = unsafe { static_init_test_cb!() }; |
There was a problem hiding this comment.
I am surprised you don't get warnings that this unsafe is not needed
bradjc
previously approved these changes
Sep 22, 2022
alistair23
reviewed
Sep 23, 2022
That is, `static_buf!()` will now panic if the same static buffer is used multiple times. This happens if the same `static_buf!()` expansion is run multiple times, such is if `static_buf!()` is in a function which is called multiple times. Since doing this causes memory to be aliased which is bad, we panic to let the board author know this needs to be fixed. Also: doc: update soundness with new static_init impl
ab89f67 to
8f80902
Compare
bradjc
previously approved these changes
Sep 23, 2022
2 tasks
8f80902 to
8fad119
Compare
8fad119 to
def33a3
Compare
alevy
approved these changes
Sep 23, 2022
|
The most recent version of this PR (which @bradjc just updated) requires |
|
There was some discussion outside GitHub about the desire for a zero-cost variant that doesn't dynamically check if a value has already been initialized, though the uses of this would likely be only out-of-tree (at least for now). I think this is pretty simple to implement, but would vote for leaving this either out-of-tree for now or doing it in a separate pull request. |
bradjc
approved these changes
Sep 23, 2022
ppannuto
approved these changes
Sep 23, 2022
|
bors r+ |
2 tasks
bors bot
added a commit
that referenced
this pull request
Sep 27, 2022
3245: boards/opentitan/tests: fixup macro syntax r=ppannuto a=twilfredo ### Pull Request Overview The following changes address the compiler warning generated [1] when building tests: Since: #3239 [1]: `warning: trailing semicolon in macro used in expression position` The exact warning: ``` warning: trailing semicolon in macro used in expression position --> boards/opentitan/earlgrey-cw310/src/tests/flash_ctrl.rs:92:6 | 92 | };}; | ^ ... 104 | let cb = unsafe { static_init_test!() }; | ------------------- in this macro invocation | = note: `#[warn(semicolon_in_expressions_from_macros)]` on by default = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #79813 <rust-lang/rust#79813> = note: macro invocations at the end of a block are treated as expressions = note: to ignore the value produced by the macro, add a semicolon after the invocation of `static_init_test` = note: this warning originates in the macro `static_init_test` (in Nightly builds, run with -Z macro-backtrace for more info) ``` ### Testing Strategy Compiling and testing on Verilator ### TODO or Help Wanted N/A ### Documentation Updated - [x] Updated the relevant files in `/docs`, or no updates are required. ### Formatting - [x] Ran `make prepush`. Co-authored-by: Wilfred Mallawa <[email protected]>
2 tasks
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull Request Overview
This pull request builds on top of #3219 , with some additional optimizations for size to reduce the overhead introduced in #3219. This PR removes
StaticUninitializedBufferandUninitializedBuffer, since I believe they now offer very little overMaybeUninittoday (other than a slightly nicer name forinitialize()vswrite().This combination of changes makes it no longer
unsafeto callstatic_init!()orstatic_buf!(). A logical followup change is to removeunsafefromstatic_buf!()and makeComponent::finalize()safe. This change should allow us to remove >90% of the unsafe code inmain.rs, a big jump forward for validating memory safety in Tock.On Imix, this brings the overhead of #3219 down to 1104 bytes. Notably, once Brad finishes porting uses of
static_init_half!()tostatic_buf!(), this overhead will increase.Apologies for the weird commit ordering, where #3219 comes after my changes -- I implemented my changes first and then pulled in the #3219 changes in a squashed commit. Ultimately I think that #3219 should just be closed in favor of this PR.
This PR also defines the expected process for a component: all statically declared memory is created in a macro and passed in to
finalize(). That macro has a naming convention of[name]_component_static!(). No memory is statically allocated infinalize()(i.e. no static_init! or static_buf! in the finalize function). That macro only statically declares memory.Testing Strategy
This pull request was tested by compiling.
TODO or Help Wanted
After this PR is merged, Brad's various component PRs will need to be rebased to useMaybeUninitas theStaticInputto components.Documentation Updated
Formatting
make prepush.