Emscripten post processing doesn't correctly update .debug_addr section

[bmeurer]

Debug fission support for Emscripten with -gsplit-dwarf (#9871) seems to mostly work, except that the post processing in Emscripten (even when linking with -O0 or -O1) doesn't update the .debug_addr table correctly, and hence the debugger is unable to resolve the address indices later.

I've uploaded a repro to https://github.com/bmeurer/split-dwarf-demo which illustrates the problem.

$ env EMCC_DEBUG=1 make
...
$ llvm-dwarfdump-10 -debug-addr /tmp/emscripten_temp/emcc-[01]-*.wasm                                                  1 ↵
/tmp/emscripten_temp/emcc-0-base.wasm:  file format WASM

.debug_addr contents:
Addr Section: length = 0x00000000, version = 0x0004, addr_size = 0x04, seg_size = 0x00
Addrs: [
0x00000007
0x00000074
0x000000a9
]
/tmp/emscripten_temp/emcc-1-wasm-emscripten-finalize.wasm:      file format WASM

.debug_addr contents:
Addr Section: length = 0x00000000, version = 0x0004, addr_size = 0x04, seg_size = 0x00
Addrs: [
0x00000007
0x00000074
0x000000a9
]

So the wasm-emscripten-finalize step apparently didn't update the .debug_addr section at all. However looking into the binaries:

$ wasm-objdump -h /tmp/emscripten_temp/emcc-[01]-*.wasm|grep Code
     Code start=0x00000216 end=0x00002cee (size=0x00002ad8) count: 50
     Code start=0x00000241 end=0x00002b33 (size=0x000028f2) count: 52
$ wasm-objdump -d /tmp/emscripten_temp/emcc-[01]-*.wasm|grep -h '^0.*foo'     
00028a func[4] <foo>:
0002b3 func[5] <foo>:

We can see that foo was originally at offset 0x74 (relative to the start of the Code section), but after the finalization step, it's at offset 0x72 (relative to Code). The .debug_addr table however still points to 0x74.

[bmeurer]

emcc-01.zip contains the two relevant emcc-[01]-*.wasm files.

cc @pfaffe

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.

[sbc100]

Is this now fixed?

[kripken]

I think this hasn't been fixed, but we've been focusing on avoiding running Binaryen at all during debugging, and that is basically achieved, so we can likely close this as not being a problem in practice. The major exception to that atm is Asyncify, which will always force Binaryen to run, but even that will go away once stack switching arrives (which is hopefully not far).