Add Pyodide WebAssembly wheel support by zardus · Pull Request #283 · angr/pypcode

zardus · 2026-07-21T19:47:25Z

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

Problem

The pypcode release workflow has no cp314-pyodide_wasm32 wheel, so browser consumers cannot import pypcode and translate the one-byte x86-64 ret input c3 at address 0x0000.

Root cause

The build coupled the nanobind extension and the host SLEIGH compiler into one CMake invocation. Under Emscripten, the target toolchain can build the extension but cannot provide the native SLEIGH executable needed to compile processor specifications.

Fix

Split the CMake targets so Emscripten builds only the extension while a sanitized host CMake environment builds SLEIGH. Add the Pyodide cibuildwheel job to the existing release workflow and make publication depend on it.

Testing

The exact-head workflow built cp314-pyodide_wasm32, imported pypcode, and asserted pypcode.Context('x86:LE:64:default').translate(b'\xc3').ops; both fresh hosted runs passed all 21 build, test, lint, wheel, and upload-test jobs. Validation: #283 (comment)

session: sharpen

zardus · 2026-07-21T19:47:40Z

Tandem PRs — please test these together:

codecov · 2026-07-21T19:53:01Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.62%. Comparing base (559aacd) to head (e340593).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #283      +/-   ##
==========================================
- Coverage   86.82%   83.62%   -3.20%     
==========================================
  Files           5        5              
  Lines         516      513       -3     
  Branches       82       98      +16     
==========================================
- Hits          448      429      -19     
  Misses         26       26              
- Partials       42       58      +16

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

zardus · 2026-08-26T15:43:40Z

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

Audited this branch against current master (559aacd). It is already exactly zero commits behind, so I preserved the existing head rather than creating a no-op rebase. Fresh native validation passes: the x86-64 translation smoke test and all 46 unit tests are green, all pre-commit hooks pass, and merge-base lint/type scores do not regress.

I also rebuilt the exact cp314-pyodide_wasm32 path with cibuildwheel 4.1.0 and Pyodide 314/Emscripten 5.0.3; the produced wheel passes the workflow real pypcode import/translation smoke test (wheel SHA-256 ab05c0ca87734921dec686a35b46a323b6020078c0796d0fcb3424748a81107b). No source changes were needed.

zardus · 2026-08-27T05:24:28Z

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

Validation record for head e340593a0ba44bead5b8e459f523518e0c13faa3 (tree 2dfa07ee67c47eb94d324c5abcc62d2660ac2e64) against master 559aacdc9d363fd19477d9daa40721279cd99248.

Rerun commit: e340593a0ba44bead5b8e459f523518e0c13faa3 is an empty rerun commit over 3e6f4adcdb9fc9f718d9ba81b7dfcf7232008ce3; both commits have tree 2dfa07ee67c47eb94d324c5abcc62d2660ac2e64, so the source tree is unchanged from the previously validated head.
Fresh hosted runs: push run 33161412194 and pull_request run 33161415510 both used head e340593a0ba44bead5b8e459f523518e0c13faa3 and completed successfully on 2026-08-28. In each run, all 21 build/test/lint/wheel/upload-test jobs succeeded and Upload wheels to PyPI was skipped.
Hosted Pyodide command: exact-head workflow .github/workflows/build.yml sets CIBW_PLATFORM: pyodide, CIBW_BUILD: cp314-pyodide_wasm32, and CIBW_TEST_COMMAND to python -c "import pypcode; assert pypcode.Context('x86:LE:64:default').translate(b'\xc3').ops". Both fresh runs passed Build Pyodide wheel.
External checks: pre-commit.ci - pr and docs/readthedocs.org:pypcode are success. codecov/patch is success and reports "Coverage not affected when comparing 559aacd...e340593"; codecov/project is failure at 83.62% (-3.20%) against 559aacd, while also reporting all modified/coverable lines covered and all tests successful. gh pr checks --required reports no required checks for this branch.
Prior artifact record: retained from head 3e6f4adcdb9fc9f718d9ba81b7dfcf7232008ce3 because the new head has the same tree. Hosted run 29863000876, job 88744245787, produced cp314-pyodide_wasm32, artifact 8508124346, size 13,803,841 bytes, with Actions digest sha256:e3b5d2292007d1751b508faea3af1df41efa8a1194508531c470bd2393471c3e; the artifact is expired and the job-log endpoint returned HTTP 410 as of 2026-08-27, so no fresh download claim is made.
Configuration: this is a direct one-instruction p-code translation; CFG and Decompiler preset are N/A. No temporary instrumentation was present. A/A is N/A because the command is a deterministic pass/fail translation assertion.
Consumer proof: Add first-class WebAssembly runtime support angr#6658 exact head 393acfff4df97d589335d9c375a2dfd36997e021 selected pypcode head 3e6f4adcdb9fc9f718d9ba81b7dfcf7232008ce3, which has the same tree as e340593a0ba44bead5b8e459f523518e0c13faa3; hosted WebAssembly run 33003145666, job 98289886449, passed its direct P-code lift of the fauxware entry block. The consumer's browser artifact 9620303339 has Actions digest sha256:67a14fb7ff39c14cd10cf15f0478448cf93ef794cf42e80f2c26ef6139a86a08.
Snapshot scope: pypcode has no decompiler-snapshot job. The consumer browser job establishes efficacy for packaged p-code translation; the consumer's separate CGC snapshot artifact is safety-only and is not restated as pypcode efficacy.

session: decbench

Empty commit; no source tree changes.

zardus · 2026-08-28T13:29:41Z

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

Full Pyodide packaging result for translating the x86-64 ret byte c3, before and after this change.

Before — the release workflow has no WebAssembly wheel path:

pypcode baseline

cp314-pyodide_wasm32 build job: absent
Pyodide pypcode import/translation smoke test: absent

After — the target extension and host SLEIGH compiler are built separately:

with this change

CIBW_PLATFORM: pyodide
CIBW_BUILD: cp314-pyodide_wasm32
smoke test: import pypcode
translation: Context('x86:LE:64:default').translate(b'\xc3').ops
hosted Build Pyodide wheel: success

#6550 moved claripy into angr.rustylib, so the WebAssembly build no longer needs a claripy wheel. It also made Z3 a link-time dependency of the Rust extension rather than a Python-level one. configure_z3() resolved Z3 against the build interpreter and raised LibError when z3-solver was not importable there. On a cross build that interpreter is the host's, and its libz3 is the wrong architecture, so the check was both fatal and pointless: the caller has already said which libz3 it wants. It now consults the interpreter only when Z3_LIBRARY_PATH_OVERRIDE is unset. Master already honoured a pre-set override, because it assigned through setdefault. Comparing the two across a pre-set, empty, blank and unset override, crossed with Z3_NO_PKG_CONFIG set and unset and with z3-solver present or not, they differ in exactly one class of state: with the override already set and z3-solver unavailable, master raises before setting anything and this does not. z3-solver 5.1.0.0 -- the version pyproject.toml already pins -- publishes a pyemscripten_2026_0_wasm32 wheel, so build_wheels.sh downloads it instead of building Z3 from source, and unpacks its libz3.so for the Rust link. That retires the z3-build-tools make shim, the Z3 checkout in CI, and the instruction to check out Z3 beside angr. The version is read out of pyproject.toml so the two cannot drift. pypcode stays an unconditional dependency, as twizmwazin asked on this pull request: the Emscripten wheel comes from angr/pypcode#283, so there is no reason to mark it out on that platform.

#6550 moved claripy into angr.rustylib, so the WebAssembly build no longer needs a claripy wheel. It also made Z3 a link-time dependency of the Rust extension rather than a Python-level one. configure_z3() resolved Z3 against the build interpreter and raised LibError when z3-solver was not importable there. On a cross build that interpreter is the host's, and its libz3 is the wrong architecture, so the check was both fatal and pointless: the caller has already said which libz3 it wants. It now consults the interpreter only when Z3_LIBRARY_PATH_OVERRIDE is unset. Master already honoured a pre-set override, because it assigned through setdefault. Comparing the two across a pre-set, empty, blank and unset override, crossed with Z3_NO_PKG_CONFIG set and unset and with z3-solver present or not, they differ in exactly one class of state: with the override already set and z3-solver unavailable, master raises before setting anything and this does not. z3-solver 5.1.0.0 -- the version pyproject.toml already pins -- publishes a pyemscripten_2026_0_wasm32 wheel, so build_wheels.sh downloads it instead of building Z3 from source, and unpacks its libz3.so for the Rust link. That retires the z3-build-tools make shim, the Z3 checkout in CI, and the instruction to check out Z3 beside angr. The version is read out of pyproject.toml so the two cannot drift. pypcode stays an unconditional dependency, as twizmwazin asked on this pull request: the Emscripten wheel comes from angr/pypcode#283, so there is no reason to mark it out on that platform. The lmdb shim reassigns its exported name -- `lmdb = _LmdbUnavailable()` when the real module is absent -- so pyright sees a variable rather than a module, and `lmdb.Environment` is not usable in a type expression. RuntimeDb annotated two of its three lmdb-typed signatures against the TYPE_CHECKING-only `lmdb_types` alias, which is never reassigned; the third now matches. The WebAssembly documentation said the build runs in a browser. It does not yet: Pyodide cannot resolve libz3.so when it loads angr.rustylib, so importing angr fails. Both files now say so.

Build pypcode wheels for Pyodide

3e6f4ad

This was referenced Jul 22, 2026

Guard optional UEFI dispatch registration angr/cle#703

Merged

Test CLE under Pyodide angr/cle#704

Merged

Trigger Build rerun for pypcode#283

e340593

Empty commit; no source tree changes.

Navigation Menu

Uh oh!

Add Pyodide WebAssembly wheel support - #283

Add Pyodide WebAssembly wheel support#283
zardus wants to merge 2 commits into
masterfrom
wasm-host-support

zardus commented Jul 21, 2026 •

edited

Loading

Uh oh!

zardus commented Jul 21, 2026 •

edited

Loading

Uh oh!

codecov Bot commented Jul 21, 2026 •

edited

Loading

Uh oh!

zardus commented Aug 26, 2026

Uh oh!

zardus commented Aug 27, 2026 •

edited

Loading

Uh oh!

zardus commented Aug 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

zardus commented Jul 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Root cause

Fix

Testing

Uh oh!

zardus commented Jul 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov Bot commented Jul 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

zardus commented Aug 26, 2026

Uh oh!

zardus commented Aug 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zardus commented Aug 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

zardus commented Jul 21, 2026 •

edited

Loading

zardus commented Jul 21, 2026 •

edited

Loading

codecov Bot commented Jul 21, 2026 •

edited

Loading

zardus commented Aug 27, 2026 •

edited

Loading