Stream: git-wasmtime

Topic: wasmtime / Issue #2853 debug: Fix frame base memory accesses

Wasmtime GitHub notifications bot (Apr 21 2021 at 13:04):

uweigand commented on Issue #2853:

Huh, this is strange. From the failing test, it appears that on x86 that address is a WebAssembly memory address. Now I'm confused as to why this would differ between platforms. What is the result of a DW_OP_WASM_location _supposed_ to be?

Wasmtime GitHub notifications bot (Apr 21 2021 at 13:05):

uweigand commented on Issue #2853:

@cfallin FYI ... this is the second issue we were talking about. Not sure what the problem here is ... see above.

Wasmtime GitHub notifications bot (Apr 21 2021 at 14:55):

bjorn3 commented on Issue #2853:

According to https://yurydelendik.github.io/webassembly-dwarf/ DW_OP_WASM_location 0 i would return the value of the i^th local. DW_OP_WASM_location 1/3 i would return the i^th global and DW_OP_WASM_location 2 i the i^th value on the operand stack. In all cases if it is an address, it is an address relative to the wasm linear memory. Only at the end do you need to convert the wasm address to native address. (if applicable at all)

Wasmtime GitHub notifications bot (Apr 21 2021 at 16:01):

uweigand commented on Issue #2853:

In all cases if it is an address, it is an address relative to the wasm linear memory.

Thanks! This is the point I was not clear about. On s390x, the value I get is in fact the native address, not a wasm linear memory address -- so if it should be a wasm address, there must be a platform bug somewhere. I'll have a look.

This also means that this PR is not the correct fix, so I'm closing it.

Last updated: Nov 22 2024 at 16:03 UTC