Stream: git-wasmtime

Topic: wasmtime / Issue #2078 DWARF reference translation bug

view this post on Zulip Wasmtime GitHub notifications bot (Jul 29 2020 at 14:05):

ggreif opened Issue #2078:

sumsX.wasm.zip
Compile sumsX.wasm:

wasmtime wasm2obj -g sumsX.wasm sumsX.o

Now inspect the DWARF in sumsX.o:

llvm-dwarfdump -debug-info sumsX.o | less

Search for dayX.
You'll find 2 occurrences:

My suspicion is that the output-side DIEs are wrongly linked. Maybe an off-by-many error, or an iterator invalidation problem?

view this post on Zulip Wasmtime GitHub notifications bot (Jul 29 2020 at 14:05):

ggreif labeled Issue #2078:

sumsX.wasm.zip
Compile sumsX.wasm:

wasmtime wasm2obj -g sumsX.wasm sumsX.o

Now inspect the DWARF in sumsX.o:

llvm-dwarfdump -debug-info sumsX.o | less

Search for dayX.
You'll find 2 occurrences:

My suspicion is that the output-side DIEs are wrongly linked. Maybe an off-by-many error, or an iterator invalidation problem?

view this post on Zulip Wasmtime GitHub notifications bot (Jul 29 2020 at 14:06):

ggreif edited Issue #2078:

Here is the file for the reproduction:
sumsX.wasm.zip

Compile sumsX.wasm:

wasmtime wasm2obj -g sumsX.wasm sumsX.o

Now inspect the DWARF in sumsX.o:

llvm-dwarfdump -debug-info sumsX.o | less

Search for dayX.
You'll find 2 occurrences:

My suspicion is that the output-side DIEs are wrongly linked. Maybe an off-by-many error, or an iterator invalidation problem?

view this post on Zulip Wasmtime GitHub notifications bot (Jul 29 2020 at 14:09):

tschneidereit commented on Issue #2078:

CC @yurydelendik

view this post on Zulip Wasmtime GitHub notifications bot (Jul 29 2020 at 19:23):

ggreif commented on Issue #2078:

Yuri explained to me the WebAssemblyRefWrapper<??> issue, it appears to be by design. The second is not a priority for me, though certainly concerning.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 29 2020 at 19:23):

ggreif edited a comment on Issue #2078:

Yuri explained to me the WebAssemblyRefWrapper<??> issue offline, it appears to be by design. The second is not a priority for me, though certainly concerning.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 29 2020 at 22:09):

yurydelendik commented on Issue #2078:

Just to reiterate the above conversation, a native debugger cannot directly access pointer/reference data, so currently JIT code transform such types into WebAssemblyPtrWrapper/WebAssemblyRefWrapper. These types contain only 32-bits __ptr field (and have some utility methods to unwrap into original types). While it is incontinent the local __vmctx has to be used to "unwrap" the referenced data, e.g. via https://github.com/bytecodealliance/wasmtime/pull/1482

The approach documented at https://github.com/bytecodealliance/wasmtime/blob/main/crates/debug/src/transform/unit.rs#L90-L106

view this post on Zulip Wasmtime GitHub notifications bot (Jul 29 2020 at 22:10):

yurydelendik edited a comment on Issue #2078:

Just to reiterate the above conversation, a native debugger cannot directly access pointer/reference data, so currently JIT code transform such types into WebAssemblyPtrWrapper/WebAssemblyRefWrapper. These types contain only 32-bits __ptr field (and have some utility methods to unwrap into original types). While it is inconvenient, the local __vmctx has to be used to "unwrap" the referenced data, e.g. via https://github.com/bytecodealliance/wasmtime/pull/1482

The approach documented at https://github.com/bytecodealliance/wasmtime/blob/main/crates/debug/src/transform/unit.rs#L90-L106

view this post on Zulip Wasmtime GitHub notifications bot (Aug 08 2020 at 10:26):

ggreif edited Issue #2078:

Here is the file for the reproduction:
sumsX.wasm.zip

Compile sumsX.wasm:

wasmtime wasm2obj -g sumsX.wasm sumsX.o

Now inspect the DWARF in sumsX.o:

llvm-dwarfdump -debug-info sumsX.o | less

Search for dayX.
You'll find 2 occurrences:

My suspicion is that the output-side DIEs are wrongly linked. Maybe an off-by-many error, or an iterator invalidation problem?

view this post on Zulip Wasmtime GitHub notifications bot (Aug 08 2020 at 10:56):

ggreif commented on Issue #2078:

@yurydelendik it turns out that wasmtime already correctly translates DW_OP_deref into an addition with the memory base followed by a dereferencing. So I am refraining from declaring the parameter type as a DW_TAG_reference_type, instead doing the dereferencing in the location expression and returning the C-style enum as DW_OP_stack_value.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 08 2020 at 11:01):

ggreif edited a comment on Issue #2078:

@yurydelendik it turns out that wasmtime already correctly translates DW_OP_deref into an addition with the memory base followed by a dereferencing. So I am refraining from declaring the parameter type as a DW_TAG_reference_type, instead doing the dereferencing in the location expression and returning the C-style enum as DW_OP_stack_value. This pretty much reduces my pain about item 1. Item 2 persists, but wasm2obj generation seems to exhibit many bugs, I also can't make sense of the .debug_line section generated by it. The offsets seem totally off.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 08 2020 at 11:02):

ggreif edited a comment on Issue #2078:

@yurydelendik it turns out that wasmtime already correctly translates DW_OP_deref into an addition with the memory base followed by a dereferencing. So I am refraining from declaring the parameter type as a DW_TAG_reference_type, instead doing the dereferencing in the location expression and returning the C-style enum as DW_OP_stack_value. This pretty much reduces my pain about item 1. Item 2 persists, but wasm2obj generation seems to exhibit many bugs, I also can't make sense of the .debug_line section generated by it. The x86 code offsets seem totally off.

Last updated: Dec 06 2025 at 06:05 UTC