docs: include Memory64 DWARF fix in LLGo release notes - #5
Conversation
There was a problem hiding this comment.
Review summary
Documentation-only change: adds one release-note bullet to LLGO.md describing LLGo Binaryen PR #4.
I verified the new line's technical claims against the actual code in src/wasm/wasm-debug.cpp (address-width selection via getAddrSize()/is64, DWARF64 initial-length handling kept separate from address width, ULEB128 discriminator encoding, and out-of-range address guards). All claims are accurate. Style, grammar, and formatting are consistent with the existing PR WebAssembly#8964 bullet. No security or performance impact.
One optional, non-blocking note is inline. Approving intent — no blocking issues.
| - `llgo` is the default and release branch. Its base is upstream `version_132` (`79dfe6b412a3c22bfdb190ed6a4d79adf734db5d`), matching Emscripten 6.0.8's expected Binaryen version. | ||
| - Changes to `llgo` are proposed from a `cpunion/binaryen` branch by a pull request targeting `xgo-dev/binaryen:llgo`. Do not push commits directly to `llgo`. Create a release tag only after the contribution PR has been reviewed and integrated. | ||
| - The LLGo patch backports [Binaryen PR #8964](https://github.com/WebAssembly/binaryen/pull/8964) to repair DWARF scope ranges after optimization and Asyncify. Backport-only test fixture changes are kept on this branch. | ||
| - [LLGo Binaryen PR #4](https://github.com/xgo-dev/binaryen/pull/4) preserves Memory64 DWARF address widths through Binaryen rewrites. It also fixes DWARF64 line-table lengths, discriminator encoding, and width-sensitive range and location markers in the bundled DWARF reader and writer. |
There was a problem hiding this comment.
Optional (non-blocking): PR #4's own description explicitly scopes out the --memory64-lowering path ("still needs DIE-reference relocation when changing compilation-unit address width"), and wasm-debug.cpp notes the lowering pass may change the architecture. The unqualified "preserves Memory64 DWARF address widths through Binaryen rewrites" could lead a reader to assume full coverage including lowering. Consider narrowing to the finalize/roundtrip/Asyncify paths the PR actually guarantees, e.g. "...through finalize, roundtrip, and Asyncify rewrites". Given the terse release-note format, leaving it as-is is also defensible.
The release workflow publishes LLGO.md verbatim. After #4 merged, those notes still listed only the WebAssembly#8964 backport, so the next Binaryen release would omit its Memory64 DWARF patch provenance. Record #4 and its DWARF fixes before tagging the next llgo-v132.N release. Validation: git diff --check; release packaging and tests will run on this PR.