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.
@MabezDev This is fixing this issue in
esp-idf-sys
.The TL;DR is that xtensa GCC aligns 64 and 128 bit values at the 4 byte boundary, while our rust
xtensa
targets align these at their default, i.e. at the 8 and 16th byte boundary, which leads to rust panicking at runtime if it finds a GCC-provided structure, which - from its POV - is misaligned.The fix is simply aligning (pun intended) the Rust/LLVM alignment spec with the one in xtensa GCC.
While this is crucial for the
esp-idf-*
crates (and therefore the-espidf
targets), I suspect it might be a thing for the baremetal targets too, considering the WIFI and BLE blobs, as well as thembed-tls
usage on baremetal (whatever the status of that last project is).Hence I touched these too.
Let me know if I have to rebase the PR against a different branch. Not really sure what is the git workflow policy of the
esp-rs
Rust fork these days.