ggreif opened Issue #2078:
sumsX.wasm.zip
CompilesumsX.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:
- as a parameter to subprogram
spell
(this is good), with a bogus type:WebAssemblyRefWrapper<??>
- as a parameter to subprogram
Text.compare_eq
(this is bogus).My suspicion is that the output-side DIEs are wrongly linked. Maybe an off-by-many error, or an iterator invalidation problem?
ggreif labeled Issue #2078:
sumsX.wasm.zip
CompilesumsX.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:
- as a parameter to subprogram
spell
(this is good), with a bogus type:WebAssemblyRefWrapper<??>
- as a parameter to subprogram
Text.compare_eq
(this is bogus).My suspicion is that the output-side DIEs are wrongly linked. Maybe an off-by-many error, or an iterator invalidation problem?
ggreif edited Issue #2078:
Here is the file for the reproduction:
sumsX.wasm.zipCompile
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:
- as a parameter to subprogram
spell
(this is good), with a bogus type:WebAssemblyRefWrapper<??>
- as a parameter to subprogram
Text.compare_eq
(this is bogus).My suspicion is that the output-side DIEs are wrongly linked. Maybe an off-by-many error, or an iterator invalidation problem?
tschneidereit commented on Issue #2078:
CC @yurydelendik
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.
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.
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/1482The approach documented at https://github.com/bytecodealliance/wasmtime/blob/main/crates/debug/src/transform/unit.rs#L90-L106
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/1482The approach documented at https://github.com/bytecodealliance/wasmtime/blob/main/crates/debug/src/transform/unit.rs#L90-L106
ggreif edited Issue #2078:
Here is the file for the reproduction:
sumsX.wasm.zipCompile
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:
- as a parameter to subprogram
spell
(this is good),with a bogus type:WebAssemblyRefWrapper<??>
- as a parameter to subprogram
Text.compare_eq
(this is bogus).My suspicion is that the output-side DIEs are wrongly linked. Maybe an off-by-many error, or an iterator invalidation problem?
ggreif commented on Issue #2078:
@yurydelendik it turns out that
wasmtime
already correctly translatesDW_OP_deref
into an addition with the memory base followed by a dereferencing. So I am refraining from declaring the parameter type as aDW_TAG_reference_type
, instead doing the dereferencing in the location expression and returning the C-styleenum
asDW_OP_stack_value
.
ggreif edited a comment on Issue #2078:
@yurydelendik it turns out that
wasmtime
already correctly translatesDW_OP_deref
into an addition with the memory base followed by a dereferencing. So I am refraining from declaring the parameter type as aDW_TAG_reference_type
, instead doing the dereferencing in the location expression and returning the C-styleenum
asDW_OP_stack_value
. This pretty much reduces my pain about item 1. Item 2 persists, butwasm2obj
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.
ggreif edited a comment on Issue #2078:
@yurydelendik it turns out that
wasmtime
already correctly translatesDW_OP_deref
into an addition with the memory base followed by a dereferencing. So I am refraining from declaring the parameter type as aDW_TAG_reference_type
, instead doing the dereferencing in the location expression and returning the C-styleenum
asDW_OP_stack_value
. This pretty much reduces my pain about item 1. Item 2 persists, butwasm2obj
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 23 2024 at 12:05 UTC