Does lldb + wasmtime support this option, i.e. with the dwarf info in a separate file ?
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?
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
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
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.
wasmtime doesn't have support for reading "split-dwarf" however
having support though would be great if you have a pr in mind!
Thanks, I will have a look around!
Scott Waye has marked this topic as resolved.
Ralph has marked this topic as unresolved.
side-loading debug bits is sooooooo common that we need wasmtime to support that eventually. Standalone debuggers do support it.
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....
For vscode, are you referring to the lldb extension or cppvsdbg ?
https://marketplace.visualstudio.com/items?itemName=ms-vscode.wasm-dwarf-debugging
right now it only supports custom data section dwarf symbols
is there a specific lldb extension you mean?
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". :-)
waddya mean, Harry Potter isn't real?
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.
I'm going to try the lldb one, too. let's mix and match experiences!
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.
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
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
?
and what is a Tumble
?
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?
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.
Ignore tumble
, guess I was smoking something (or my repo was out of date)
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
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
hm as a non-dwarf-expert I'm not seeing anything out of the ordinary in terms of sections, just the standard .debug_*
sections
this looks like standard library debug info was included but then debug info was also split off
hm, ok, let me compare to without -gseparate-dwarf
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
cargo run --bin dwarfdump ~/code/wasmtime/console.wasm | rg dwp
prints nothing
so it appears that the wasm itself does not indicate that it was built with split dwarf
which would mean that the user would have to manually say "I split the dwarf here"
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
so this might be something where upstream llvm may need a patch or two to get the best ux here
I suppose for native target symbols add xxx.dwp
works, although not tried
oh is that required for native? lldb doesn't automatically find the *.dwp
?
let me try
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.
Maybe of interest here https://github.com/llvm/llvm-project/pull/77949 (gdb remote work)
oh nice! I've wondered what it might take to have a wasm native target for remote debugging
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
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.
if we want it, it would just require a bit of socializing and paolo would be glad to resubmit
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
).
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.
Is the wasmtime dwarf parser v4 or v5 ?
maybe a better question is dwarf5 v4 plus new stuff, or not compatible at all.
I don't know myself, but I'm relatively sure it uses the gimli
crate which I suspect supports v5
but there's lots of manual handling of things so I'm not sure it handles everything
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.
Thanks, wasmtime also looks like it could do with Attribute::String(R)
support
why does wasmtime have to clone attributes, clone_die_attributes
?
I will try adding the String
support first, might help get a little more familiar with things, thanks for the replies
clone_die_attributes
rewrites all attributes to reference the addresses and layouts of the compiled machine code rather than the original wasm module.
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: Dec 23 2024 at 13:07 UTC