Stream: wasmtime

Topic: gseparate-dwarf support?

Scott Waye (Jan 19 2024 at 15:48):

Does lldb + wasmtime support this option, i.e. with the dwarf info in a separate file ?

Alex Crichton (Jan 19 2024 at 15:51):

wasmtime has basic support by processing dwarf, but I haven't heard of generate-dwarf as a concept, so is that like a standard or something other runtimes do?

Scott Waye (Jan 19 2024 at 15:52):

emscripten can do this, where the advantage is admittedly more obvious, the dwarf info resides (mostly) in a separate file meaning the main wasm is downloaded and started faster and the dward only loaded if the debugger is opened

Alex Crichton (Jan 19 2024 at 15:53):

oh I think that's more of a toolchain thing than a wasmtime thing, and it's probably some various llvm flags to get that to work

Scott Waye (Jan 19 2024 at 15:53):

We have this working for c#/AOT in https://github.com/dotnet/runtimelab/pull/2264 and I was hoping I could make it work for wasmtime also, although the payoff there is not so great.

Alex Crichton (Jan 19 2024 at 15:53):

wasmtime doesn't have support for reading "split-dwarf" however

Alex Crichton (Jan 19 2024 at 15:53):

having support though would be great if you have a pr in mind!

Scott Waye (Jan 19 2024 at 15:58):

Thanks, I will have a look around!

Notification Bot (Jan 19 2024 at 15:58):

Scott Waye has marked this topic as resolved.

Notification Bot (Jan 19 2024 at 16:36):

Ralph has marked this topic as unresolved.

Ralph (Jan 19 2024 at 16:36):

side-loading debug bits is sooooooo common that we need wasmtime to support that eventually. Standalone debuggers do support it.

Ralph (Jan 19 2024 at 16:38):

the vscode wasm dwarf debugger will support both embedded and standalone as no one wants to ship debug symbols to prod but we do need sometimes to debug the specific prod module....

Scott Waye (Jan 19 2024 at 16:42):

For vscode, are you referring to the lldb extension or cppvsdbg ?

Ralph (Jan 19 2024 at 17:30):

https://marketplace.visualstudio.com/items?itemName=ms-vscode.wasm-dwarf-debugging

Ralph (Jan 19 2024 at 17:31):

right now it only supports custom data section dwarf symbols

Ralph (Jan 19 2024 at 17:31):

is there a specific lldb extension you mean?

Ralph (Jan 19 2024 at 17:46):

Ralph said:

side-loading debug bits is sooooooo common that we need wasmtime to support that eventually. Standalone debuggers do support it.

BTW, I really do mean eventually and people who want it need to pony up the work for it, of course. Stuff doesn't happen "by magic". :-)

Scott Waye (Jan 19 2024 at 17:58):

waddya mean, Harry Potter isn't real?

Scott Waye (Jan 19 2024 at 18:00):

https://marketplace.visualstudio.com/items?itemName=vadimcn.vscode-lldb is the one I've used before, it works most of the time. But I will check out your link - as it is based on the chrome extension (which does support separate dwarf) we might be close.

Ralph (Jan 19 2024 at 19:10):

I'm going to try the lldb one, too. let's mix and match experiences!

Scott Waye (Jan 19 2024 at 19:16):

To clarify the ambiguity in what I wrote, when I said it works, it works with embedded dwarf, I've not tried it with side loading.

Scott Waye (Jan 20 2024 at 16:57):

Ralph said:

https://marketplace.visualstudio.com/items?itemName=ms-vscode.wasm-dwarf-debugging

I tried node, but unfortunately it doesn't seem able to run wasm modules that we build and that we run with wasmtime. node just crashes during its compilation step. I will try CodeLLDB next

Scott Waye (Jan 21 2024 at 14:53):

Alex Crichton said:

having support though would be great if you have a pr in mind!

Would this start with append_dwarf in compilation.rs ?

Scott Waye (Jan 21 2024 at 14:54):

and what is a Tumble ?

Alex Crichton (Jan 22 2024 at 18:45):

It might start there yeah, although I don't think I know enough about what this feature is to suggest the best route forward. Is the goal to generate native DWARF for the cranelift-compiled code? (using the wasm dwarf as input)

As for Tumble, is that in Wasmtime or somewhere else?

Scott Waye (Jan 22 2024 at 18:50):

lldb with wasmtime and a dwarf embedded in the wasm works fine, however if the dwarf is separated using -gseparate-dwarf to clang to generate a ....wasm.dwp then it seems lldb does not find the dwp package , which perhaps is because wasmtime does not "tell" lldb about it when -Ddebug-info is used. To be honest I've not looked at how debug-info works.

Scott Waye (Jan 22 2024 at 19:00):

Ignore tumble, guess I was smoking something (or my repo was out of date)

Alex Crichton (Jan 22 2024 at 19:00):

if you're using lldb on wasmtime then it's probably relying on the built-in translation Wasmtime performs from "wasm dwarf" to "native dwarf". Wasmtime then informs lldb of this via debugger-specific things and lldb hooks into it all at that point.

So my guess here is that Wasmtime doesn't support loading "wasm dwarf" when it's split out. (which is what happens with -gseparate-dwarf). Wasmtime's compilation model doesn't lend itself well to probing the filesystem, currently it only supports "here's the bytes plz compile" so we'd need to refactor the internals of the Module constructors. I could see though that if you use Module::from_file we could have automatic support for reading the metadata and finding the dwarf file

Alex Crichton (Jan 22 2024 at 19:00):

Do you have a sample wasm module which was compiled with -gseparate-dwarf? I'm curious to poke around in there and see if there's metadata to find the split-dwarf file

Scott Waye (Jan 22 2024 at 19:05):

console.wasm.zip

Alex Crichton (Jan 22 2024 at 19:10):

hm as a non-dwarf-expert I'm not seeing anything out of the ordinary in terms of sections, just the standard .debug_* sections

Alex Crichton (Jan 22 2024 at 19:10):

this looks like standard library debug info was included but then debug info was also split off

Scott Waye (Jan 22 2024 at 19:11):

hm, ok, let me compare to without -gseparate-dwarf

Alex Crichton (Jan 22 2024 at 19:13):

ok I'm running the gimli repository which has a dwarfdump example to print out a debug view of all the dwarf info on the console.wasm

Alex Crichton (Jan 22 2024 at 19:13):

cargo run --bin dwarfdump ~/code/wasmtime/console.wasm | rg dwp prints nothing

Alex Crichton (Jan 22 2024 at 19:13):

so it appears that the wasm itself does not indicate that it was built with split dwarf

Alex Crichton (Jan 22 2024 at 19:13):

which would mean that the user would have to manually say "I split the dwarf here"

Alex Crichton (Jan 22 2024 at 19:14):

but afaik split dwarf on native platforms doesn't do that, they have self-discoverable paths where you can find everything just from the original binary

Alex Crichton (Jan 22 2024 at 19:14):

so this might be something where upstream llvm may need a patch or two to get the best ux here

Scott Waye (Jan 22 2024 at 19:16):

I suppose for native target symbols add xxx.dwp works, although not tried

Alex Crichton (Jan 22 2024 at 19:17):

oh is that required for native? lldb doesn't automatically find the *.dwp?

Scott Waye (Jan 22 2024 at 19:17):

let me try

Scott Waye (Jan 23 2024 at 01:25):

You are right, if the dwp file is named as the executable plus .dwp then it works. Looks like it is loading via convention. Could we not do the same? I'm not clear what we need changing upstream in llvm.

Scott Waye (Jan 23 2024 at 14:32):

Maybe of interest here https://github.com/llvm/llvm-project/pull/77949 (gdb remote work)

Alex Crichton (Jan 23 2024 at 15:55):

oh nice! I've wondered what it might take to have a wasm native target for remote debugging

Alex Crichton (Jan 23 2024 at 15:55):

but if *.dwp is a convention then we could perhaps bake that into wasmtime::Module::from_file to load a *.dwp as the dwarf info if it exists

Ralph (Jan 23 2024 at 16:25):

related: Paolo did not know who in the llvm community would help him merge that llvm pr, but it IS the pr that the wamr dwarf support is based on.

Ralph (Jan 23 2024 at 16:26):

if we want it, it would just require a bit of socializing and paolo would be glad to resubmit

Philip Craig (Jan 30 2024 at 07:55):

Alex Crichton said:

cargo run --bin dwarfdump ~/code/wasmtime/console.wasm | rg dwp prints nothing

The relevant attributes have dwo in the name, not dwp. A DWARF package file (dwp) contains a number of DWARF objects (dwo).

Scott Waye (Jan 30 2024 at 20:22):

Its a dwp that I'm interested in loading. I'm still looking at the wasmtime code to see how it works regards loading dwarf and passing it on to lldb.

Scott Waye (Feb 01 2024 at 01:02):

Is the wasmtime dwarf parser v4 or v5 ?

Scott Waye (Feb 01 2024 at 01:23):

maybe a better question is dwarf5 v4 plus new stuff, or not compatible at all.

Alex Crichton (Feb 01 2024 at 04:06):

I don't know myself, but I'm relatively sure it uses the gimli crate which I suspect supports v5

Alex Crichton (Feb 01 2024 at 04:07):

but there's lots of manual handling of things so I'm not sure it handles everything

Philip Craig (Feb 01 2024 at 12:40):

dwarf5 is v4 plus new stuff. gimli should support both (might be some obscure parts of v5 that aren't implemented yet). The dwarfdump example in gimli can load dwp files. You'll need to change wasmtime to do the same.

Scott Waye (Feb 01 2024 at 12:42):

Thanks, wasmtime also looks like it could do with Attribute::String(R) support

Scott Waye (Feb 01 2024 at 12:43):

why does wasmtime have to clone attributes, clone_die_attributes ?

Scott Waye (Feb 01 2024 at 12:45):

I will try adding the String support first, might help get a little more familiar with things, thanks for the replies

bjorn3 (Feb 01 2024 at 16:26):

clone_die_attributes rewrites all attributes to reference the addresses and layouts of the compiled machine code rather than the original wasm module.

Scott Waye (Feb 01 2024 at 16:28):

Thanks, I was wondering about that and where that code was, I see more clearly now, some can be passed through, others require the translaction.

Last updated: Nov 22 2024 at 16:03 UTC