DWARF support in custom compiler · general

I'm trying to add DWARF support to my Java-to-Wasm compiler. However, when I try to run generated wasm file in gdb/wasmtime, I got no result, .debug_X sections are silently ignored. I tried to verify DWARF sections using following approach: (1) create an ELF file (2) extract .debug_X sections into files (3) add these sections to ELF file using objcopy (4) use objdump/dwarfdump/llvm-dwarfdump to verity DWARF. So my question is: what are further steps to debug my issue? Is there any way to get more logs from wasmtime related to DWARF supports?

Alexey Andreev (Nov 19 2022 at 12:16):

Update: seems that wasmtime recognizes DW_TAG_subprogram, however no line information available.

bjorn3 (Nov 19 2022 at 15:09):

bjorn3 (Nov 19 2022 at 15:10):

You can't just copy the debuginfo from the wasm file to compiled object files. The debuginfo needs to be translated by the wasm engine to fixup references and translate variable locations.

Alexey Andreev (Nov 19 2022 at 16:53):

Sure. That was not my intention. I just wanted to verify generated DWARF sections. I know only tools from non-Wasm world, that's why I needed this trick. I create ELF file from random simple C code and then embed DWARF there, since objdump only works with ELF. Of course, I'm not trying to debug this.

Alexey Andreev (Nov 19 2022 at 17:02):

Update: I tried to emit DW_LNE_END_SEQUENCE after each function, not at the end of code section, and got following panic from wasmtime:

thread 'main' panicked at 'explicit panic', crates/cranelift/src/debug/transform/line_program.rs:160:26
stack backtrace:
   0: rust_begin_unwind
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:142:14
   2: core::panicking::panic
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:48:5
   3: wasmtime_cranelift::debug::transform::line_program::clone_line_program
   4: wasmtime_cranelift::debug::transform::unit::clone_unit
   5: wasmtime_cranelift::debug::transform::transform_dwarf
   6: wasmtime_cranelift::debug::write_debuginfo::emit_dwarf
   7: <wasmtime_cranelift::compiler::Compiler as wasmtime_environ::compilation::Compiler>::emit_obj

Alexey Andreev (Nov 19 2022 at 19:24):

Ok, I found the reason. I added DW_LNE_END_SEQUENCE after the function, even if the function did not produce any line instructions. And this did the trick. So looks like wasmtime rejects .debug_line section with only one large sequence, it requires a separate sequence for each subprogram.

Stream: general