chore(evm-polkavm): align polkavm to 0.33.1 and enforce the sbrk-free ISA - #141
Closed
nol4lej wants to merge 33 commits into
Closed
chore(evm-polkavm): align polkavm to 0.33.1 and enforce the sbrk-free ISA#141nol4lej wants to merge 33 commits into
nol4lej wants to merge 33 commits into
Conversation
…fc-* test-target split
…ner survive low memory
…and wire the benchmarked weights
…e upstream verification
…A, and fix the guest ABI and slice panics
# Conflicts: # Cargo.lock
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
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.
Why
frame/evm-polkavmpinnedpolkavm 0.29.1while the SDK 2606 executor (sc-executor-polkavm 0.44.0) runs 0.33.1, soCargo.lockcarried both copies in one binary. Registered as debt during the 2606 migration; this clears it.What changed
Aligned to 0.33.1. Four duplicate crates dropped from the lockfile (
polkavm,-assembler,-common,-linux-rawat 0.29), none added.polkavm-deriveinuapiwent 0.30.0 → 0.33.0 to match.The sbrk guarantee moved, so it is now enforced where code enters the chain.
ModuleConfig::set_allow_sbrk(false)is gone in 0.33, the blob's ownInstructionSetKinddecides whether the opcode decodes, andpolkavm-linkertakes theISA as a required argument, so it is chosen by whoever compiled the contract. The pallet cannot assume it, so
create_polkavmnow validates:sbrk?ReviveV1,JamV1Latest32,Latest64A whitelist, not a blocklist: a future ISA is rejected until someone checks it. Memory growth changes gas consumption and this is consensus code.
Three slice panics fixed.
AccountCodes::getreturns an emptyVecfor any address without contract code, and bothexecuteandis_precompileindexed it withcode[0..8], so a call to a plain account panicked.create_polkavmhad the same shape (its length check is an upper bound only).The riscv64 guest ABI now compiles.
uapi/src/host/riscv64.rsfailed with twoE0432errors: five imports pointing at paths that do not exist in this crate, pluspallet_revive_proc_macro, which was never a dependency. None of them were used, all served host functions this crate does not declare. Broken since the upstream commit that introduced it, unnoticed because nothing built for that target.A CI step that builds it, with the target installed in the job rather than in
rust-toolchain.toml, so a normal build does not pay for a ~100 MB std nobody else needs.Testing
Latest32fails,breaking the fixture's ISA mapping fails, restoring
code[0..8]failscargo checkfor the pallet, the benchmarking feature, and the whole workspacecargo build -p pallet-evm-polkavm-uapi --target riscv64imac-unknown-none-elf --release— 466 KB rlib carrying the ABI symbols
cargo fmt,clippy --all-targetsNote
The pallet is still not wired into any runtime, no
construct_runtime!entry, nothing outside the crate depends on it. This makes it sound, not live. A follow-up would need runtime wiring, a contract toolchain, and end-to-end execution tests.The three bug fixes were sent upstream as polkadot-evm/frontier#1923; the version bump and the ISA policy stayed here, since the policy is ours to choose.