Generate debug info for LLDB/GDB

[yurydelendik]

• Updates wasm2obj to embed .debug_XXX section into object file
• Updates wasmtime:
  • to support JIT interface to GDB
  • generate proper information to work with LLDB

Example:

$ ../llvm-lldb/bin/lldb target/debug/wasmtime -- fib2.wasm --invoke=test
(lldb) b fib
(lldb) r
Process 53880 launched: 'wasmtime' (x86_64)
1 location added to breakpoint 1
Process 53880 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x00000001019d3047 JIT(0x102856200)`fib(n=<unavailable>) at fib2.c:2:13
   1   	int fib(int n) {
-> 2   	  int i, t, a = 0, b = 1;
   3   	  for (i = 0; i < n; i++) {
   4   	    t = a;
   5   	    a = b;

See also parent #46

P.S. work towards https://yurydelendik.github.io/webassembly-dwarf/#aot-jit-compilers

[fitzgen]

Why a new Reader trait instead of using gimli::Reader directly? To hide the associated types?

[yurydelendik]

I took it from gimli's examples/dwarfdump.rs -- it is the only syntax I could find atm

[philipc]

Your method of transforming the line program is not what I expected. It looks like it is a 1-1 mapping of line program instructions, with the only transformation being for the address for each line program instruction. I don't know enough about cranelift to know if that is valid though. For example, can cranelift do optimizations (eg reorder/combining) that mean either

• the transformed addresses are no longer monotonically increasing (we'll hit a panic in LineProgram::generate_row)
• there isn't a transformed address (we'll hit a panic in AddrTransform::translate)

I was expecting you would need to generate a new line program, with the file/line information for each address being determined by looking up the srcloc in the original line program.

[yurydelendik]

Your method of transforming the line program is not what I expected. It looks like it is a 1-1 mapping of line program instructions, with the only transformation being for the address for each line program instruction.

I was expecting you would need to generate a new line program, with the file/line information for each address being determined by looking up the srcloc in the original line program.

You are correct. Currently I'm just trying to introduce the basics like JIT interface for LLDB, and then continue building on it. Anyway, I changed the logic in the .debug_line generation to be closer to what I planned.

[sunfishcode]

Very cool!

[sunfishcode]

Ok great, let's land this and #59 now.

[m4b]

Wanted to say this is really cool and exciting, great work !

[bjorn3]

@yurydelendik how do you get this to work with lldb? When I ran lldb -- wasmtime -g ../../target/wasm32-unknown-wasi/release/rustc_binary.wasm example.rs the backtrace didn't have any symbols before wasmtime_call.

[yurydelendik]

@yurydelendik how do you get this to work with lldb? When I ran lldb -- wasmtime -g ../../target/wasm32-unknown-wasi/release/rustc_binary.wasm example.rs the backtrace didn't have any symbols before wasmtime_call.

@bjorn3 https://gist.github.com/yurydelendik/4103d782dfc62634bc9f4de98de20835 has a log of running wasmtime w/lldb. (works on linux, and requires trunk lldb build + config on macos)

[bjorn3]

requires trunk lldb build + config on macos

That seems to be the problem. I tried xcode lldb on macos. On linux it does work with lldb, but not with gdb.