Debug intrinsics do not work in the released version of wasmtime on Windows

[SingleAccretion]

Reproduction:

1. Obtain wasmtime.exe from the released artifacts. You will also need LLDB.
2. Run: lldb wasmtime -Ddebug-info -Oopt-level=0 <any WASM file with debug info>.
3. Place a breakpoint on any WASM frame.
4. Execute p __vmctx->set().

Expected result: it works.
Actual result:

error: Couldn't look up symbols:
  set_vmctx_memory_27_0_0

This is because the symbol is not present anywhere visible to LLDB. On Unix-likes it will be in the symbol table, which Windows doesn't have. And #[export_name] doesn't do anything for executables (rust-lang/rust#84161).

(lldb) image dump symtab wasmtime.exe:

Symtab, file = C:\Program Files\Wasmtime\bin\wasmtime.exe, num_symbols = 2:
               Debug symbol
               |Synthetic symbol
               ||Externally Visible
               |||
Index   UserID DSX Type            File Address/Value Load Address       Size               Flags      Name
------- ------ --- --------------- ------------------ ------------------ ------------------ ---------- ----------------------------------
[    0]      1   X Data            0x0000000141b396c0 0x00007ff7f9b996c0 0x0000000000005fb8 0x00000000 __jit_debug_descriptor
[    1]      2   X Code            0x0000000141158dc0 0x00007ff7f91b8dc0 0x0000000000161ec0 0x00000000 __jit_debug_register_code

Of note is the fact that if you build wasmtime locally, this works fine because LLDB synthesizes symbols using wasmtime's PDB.

I wonder if we could use the mechanism that libcalls use via a (dynamically) relocatable DWARF DIE for the debug intrinsics with an explicit entry point address, instead of utilizing the platform-specific symbol lookup mechanisms.

Edit: working on this...

[alexcrichton]

Oh dear, thanks for finding this! I see you're working on this but wanted to leave a comment as well saying I like the idea of using the relocation phase for dwarf for this to avoid needing to deal with symbols 👍