meld fuse produces DWARF that fails llvm-dwarfdump --verify (534 out-of-parent + 480 overlapping ranges) while inputs verify clean

[avrabe]

Filed by the PulseEngine challenge harness (meld v0.37.0, aarch64-apple-darwin). Confirmed by a differential against llvm-dwarfdump --verify with a clean input baseline.

Defect

meld fuse produces a core module whose merged .debug_* sections fail llvm-dwarfdump --verify — hundreds of overlapping / out-of-parent DIE address ranges and invalid locations — even though the inputs' DWARF is valid. The DWARF .debug_* relocator/merger (#130, #208, #144, all closed) is emitting inconsistent address ranges for the fused/reduced code.

Repro

F=tests/wit_bindgen/fixtures
meld fuse $F/records.wasm $F/variants.wasm -o fused.wasm     # 41.4% reduction
llvm-dwarfdump --verify fused.wasm

error: Aggregated error counts:
error: DIE address ranges are not contained by parent ranges occurred 534 time(s).
error: DIEs have overlapping address ranges occurred 480 time(s).
error: Invalid DWARF expressions occurred 18 time(s).
error: Invalid DW_AT_location occurred 17 time(s).
Errors detected.

Single-component fusion is also affected: meld fuse records.wasm -o single.wasm (32.1% reduction) → 272 overlapping + 230 not-contained.

Clean-room baseline (rules out "inputs were already broken")

llvm-dwarfdump --verify can't read the component wrapper directly (reports a bogus invalid version number: 65549), so I extracted the inputs' inner core modules with wasm-tools (not meld) and verified those:

wasm-tools component unbundle $F/records.wasm --module-dir mods --output /dev/null
llvm-dwarfdump --verify mods/unbundled-module0.wasm   # -> No errors.
llvm-dwarfdump --verify mods/unbundled-module1.wasm   # -> No errors.

Both inner core modules verify clean. So the overlapping/uncontained ranges are introduced by meld's fuse transform, not inherited from the inputs.

Why it matters

The fused output is what Loom optimizes and Synth compiles; a debugger (or witness MC/DC / source-map tooling that consumes this DWARF) resolving an address to a DIE gets ambiguous or wrong results. For a toolchain aimed at source-level debugging of safety-critical firmware, silently-invalid DWARF after fusion defeats the purpose of the relocator feature.

Likely cause

The 41.4% / 32.1% size reductions indicate code is removed/merged during fusion, but the .debug_* address ranges are not consistently updated to the fused layout, so DIE ranges collide and escape their parents. The relocator needs to drop/rebuild ranges for removed/merged code (or the merge must preserve a 1:1 code mapping for the DWARF it keeps).

Note

Regression probe in the challenge harness: harness/meld_dwarf_fusion_probe.sh (differential vs unbundled-input baseline).

[avrabe]

Reproduced + root-caused — two distinct causes, both bounded

Reproduced exactly (meld v0.37.0 build): records+variants → 534 not-contained / 480 overlapping / 18 invalid-expr / 17 invalid-loc; records-only → 230 / 272. --dwarf strip → "No errors" (confirms it's the remap path, and gives the safe fallback).

Cause #1 — the 534 + 480 (~96%): DW_AT_high_pc-as-length is never remapped

rewrite_debug_sections drives relocation through gimli::write::Dwarf::from(.., convert_address) (dwarf.rs:499). gimli only routes address-form values through convert_address; rustc/LLVM emit DW_AT_high_pc as DW_FORM_udata — a length — which gimli copies verbatim. low_pc, CU DW_AT_ranges pairs, and line addresses all remap correctly, but fused function bodies change length (LEB re-encode of the merged index space), so every subprogram/lexical-block/inlined DIE becomes [remapped_low, remapped_low + STALE_input_length):

• function grew → range ends past its correctly-remapped parent → not contained (e.g. CU ranges [0xd116,0xd146) vs subprogram [0xd116, 0xd116+51) = 3 bytes over);
• function shrank → stale end overruns the next function's remapped low_pc → overlapping (e.g. run_ctors_once [0xae99,+9) overlaps as_i32 [0xaea0,+11)).

This is exactly the fidelity caveat noted at dwarf.rs:422-428 (LS-D-1), filed as a benign LEB-drift nit — it is in fact this defect. Not dedupe-aliasing / dropped-code (those tombstone correctly via build_remap_for_module building spans only from surviving merged.functions); the overlaps are all between surviving functions.

Cause #2 — the 18 + 17: .debug_loc tombstone collides with the base-selection escape

convert_address tombstones unmapped in-range addresses to 0xFFFFFFFF (dwarf.rs:467/496). In DWARF v4 .debug_loc, an entry whose begin is 0xFFFFFFFF is the reserved base-address-selection escape — so a tombstoned entry derails parsing of the rest of that list (<decoding error>, impossible ranges). Small counts (only vars whose live range touches unmapped code).

Fix plan (bounded, not a rework)

• Inc 0 (safety, immediate): meld must never emit invalid DWARF — add a post-write self-check that falls back to Strip when the remapped output isn't internally valid (Remap is the default since v0.25.0). Matches meld's "strip rather than emit wrong DWARF" stance.
• Inc 1 (~96%): remap DW_AT_high_pc lengths. The remap already computes the needed value (translate(low+len) − translate(low)); patch it as a .debug_info pre-pass over DW_TAG_subprogram/lexical_block/inlined_subroutine. Oracle: llvm-dwarfdump --verify clean.
• Inc 2 (18+17): stop writing 0xFFFFFFFF as a loc/range-list entry begin (omit unmapped entries).

Existing tests only assert low_pc translated (ls_d_1_remap_translates_low_pc) and never check high_pc/containment — that's the missing invariant. Starting on the fix.

[avrabe]

Inc 1 landing — DW_AT_high_pc length remap (Cause #1 fixed)

Implemented the high_pc-length correction. Measured against the exact repro:

	before	after inc 1
DIEs overlapping	480	0
ranges not contained by parent	534	11
Invalid DWARF expressions	18	18
Invalid DW_AT_location	17	17
total	1049	46

(records+variants; single-component records: 1049-class → 4 not-contained + 3 + 5.)

How: after gimli's conversion, walk the write DIEs and rewrite each low_pc+high_pc-length pair via a new AddressRemap::corrected_high_pc — invert the remap for low_pc inside its output body, then use the span's output_body_end for a range ending at the function end (avoids the aliased-boundary translate() None) or translate for interior ends (lexical blocks / inlined subroutines). Tombstoned dropped-code low_pc is left alone (llvm-dwarfdump ignores those DIEs). Unit-tested (grew / shrank / interior / tombstone) so it doesn't need llvm-dwarfdump in CI.

Remaining (distinct mechanisms, follow-up increments):

• 11 / 4 not-contained — nested DW_AT_ranges (.debug_ranges/rnglists) on DW_TAG_inlined_subroutine / DW_TAG_lexical_block escaping their parent subprogram. Not the high_pc-length class; needs range-list handling.
• 18 / 3 + 17 / 5 invalid-expr / invalid-loc — Cause Add formal verification proofs and spec-sync tooling #2: .debug_loc entries tombstoned to 0xFFFFFFFF collide with the DWARF base-address-selection escape and derail list parsing.

PR incoming (inc 1). #319 stays open until inc 2/3 clear the residual to --verify clean.

[avrabe]

Inc 2 residual — characterized (deeper than inc 1)

The remaining 11/4 not-contained are DW_TAG_inlined_subroutine DIEs whose DW_AT_ranges land far outside their parent subprogram's range. Concrete (single-records): parent write = [0x133b6, 0x1353d) (low_pc + corrected high_pc), but its inlined child wasip2_handle_write_error has DW_AT_ranges [0x1c439,0x1c444) [0x1c449,0x1c466) — a different output region entirely.

So this is not the high_pc-length class (inc 1) — it's inlined/cold-split code whose remapped range-list entries don't stay within the (contiguous low/high) parent. Either the input parent used DW_AT_ranges to cover discontiguous inline regions and the remap collapsed it to low/high, or the inlined instance's range-list addresses remap to a location the parent's single range no longer covers. Needs its own investigation of the .debug_ranges/rnglists convert path + how fusion relocates split/inlined code relative to its enclosing function. Tracking as inc 2 (distinct from inc 3 = the .debug_loc tombstone/base-selection issue).

Inc 1 (#320, DW_AT_high_pc lengths) is green + Mythos-cleared and stands on its own (overlapping 480→0, 96% of errors). Inc 2/3 build on it.

[avrabe]

Inc 2 refinement (empirical, input vs output): the failing inlined wasip2_handle_write_error is cold-split/outlined — in the input, write = [0xb398,0xb53c) and the inlined child uses DW_AT_ranges; after fusion write's hot body remaps to [0x133b6,0x1353d) while the child's ranges remap to [0x1c439,…], a separate output region. So the child's range addresses live in a different code region than the hot body, and the remap relocates the two independently → the child escapes its nominal parent. Inc 2 = handle discontiguous inline/cold-split ranges consistently with their parent (or drop them when they can't be kept contained). Deeper than inc 1; a dedicated session, not a loop-tick patch. Inc 1 (#320) stands: all overlapping gone + 96% of errors.

[avrabe]

Inc 2 fixed — DW_AT_ranges base-offset remap (PR #321)

The "not contained in parent" class is eliminated:

	before inc 1	after inc 1	after inc 2
overlapping	480	0	0
not-contained	534	11	0
invalid-expr	18	18	18
invalid-loc	17	17	17
total (records+variants)	1049	46	35
total (records-only)	~510	12	8

Root cause was exactly the inc-1 class one level down: DWARF v4 .debug_ranges are base-relative offset pairs; gimli routed the offsets through convert_address, which remapped a small offset as an absolute address → the range escaped its parent. Fixed by correct_die_ranges (resolve absolute input ranges via die_ranges, translate endpoints, re-emit as OffsetPair relative to the output CU base; drop unmappable/dead sub-ranges — LS-D-1).

Remaining = inc 3 only: the 35/8 residual is entirely Cause #2 — .debug_loc location-list entries tombstoned to 0xFFFFFFFF collide with the DWARF base-address-selection escape, derailing list parsing (18 invalid-expr + 17 invalid-loc). That's the last class to reach --verify clean.