Stream: git-wasmtime

Topic: wasmtime / issue #7911 Question: DebugInfoData and wasm_file


view this post on Zulip Wasmtime GitHub notifications bot (Feb 10 2024 at 01:50):

yowl opened issue #7911:

Hi,

I'm trying to prepare a PR to add split wasm support, and I think I'd like to set wasm_file on DebugInfoData to the name of the wasm file being processed. Would that be an appropriate use of wasm_file?

Probably set it here:
https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasmtime/src/compile.rs#L69

So I can use it somewhere around here
https://github.com/bytecodealliance/wasmtime/blob/2c6f38622d3b009293437839e5d75b4df64fa774/crates/cranelift/src/debug/transform/mod.rs#L88
if we encounter gimli::UnitType::Skeleton, The wasm module will contain the name of the dwo, however if the dwo files were packaged into a dwp then that name is arbirtrary and as far as I can see we can load it by convention, i,e, wasm file with the extension changed to .dwp or perhaps it can be an option passed to wasmtime, but in a later PR. Chrome loads .dwp by convention it seems, and emscripten follows that conventions. (I'm getting this info from https://developer.chrome.com/blog/faster-wasm-debugging/)

Thanks,

view this post on Zulip Wasmtime GitHub notifications bot (Feb 12 2024 at 15:19):

alexcrichton commented on issue #7911:

Seems reasonable to me yeah, I had no idea this field even existed myself! I do think we'll want to be a little careful about the filesystem access though since using Module::new for example probably shouldn't go off reading the filesystem. When using Module::from_file, however, reading the filesystem seems reasonable, but we probably don't want to read the dependent object files for each function and we'll want to make sure it only happens at most once.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 14 2024 at 00:52):

yowl commented on issue #7911:

I wonder if I can ask for some more advice. I would like to pass the dwarf in here
https://github.com/bytecodealliance/wasmtime/blob/85ffc394a77d06bea15f460c78251651d154aaae/crates/wasmtime/src/compile.rs#L661
At least that's my current thinking. If I load the dwarf in Module::from_file then I can store it in Module or ModuleInner I guess, but how would I access that in link_and_append_code, pass it all the way around?

view this post on Zulip Wasmtime GitHub notifications bot (Feb 14 2024 at 15:14):

alexcrichton commented on issue #7911:

It'll likely want to get attached somewhere within ModuleTranslation along the way. For a Module::from_file that's probably threading an option down into Module::from_binary which indicates that reading from the filesystem is ok or similar

view this post on Zulip Wasmtime GitHub notifications bot (Mar 06 2024 at 01:28):

yowl closed issue #7911:

Hi,

I'm trying to prepare a PR to add split wasm support, and I think I'd like to set wasm_file on DebugInfoData to the name of the wasm file being processed. Would that be an appropriate use of wasm_file?

Probably set it here:
https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasmtime/src/compile.rs#L69

So I can use it somewhere around here
https://github.com/bytecodealliance/wasmtime/blob/2c6f38622d3b009293437839e5d75b4df64fa774/crates/cranelift/src/debug/transform/mod.rs#L88
if we encounter gimli::UnitType::Skeleton, The wasm module will contain the name of the dwo, however if the dwo files were packaged into a dwp then that name is arbirtrary and as far as I can see we can load it by convention, i,e, wasm file with the extension changed to .dwp or perhaps it can be an option passed to wasmtime, but in a later PR. Chrome loads .dwp by convention it seems, and emscripten follows that conventions. (I'm getting this info from https://developer.chrome.com/blog/faster-wasm-debugging/)

Thanks,

view this post on Zulip Wasmtime GitHub notifications bot (Mar 06 2024 at 01:28):

yowl commented on issue #7911:

Thanks very much for the help, I have something working I think

![image](https://github.com/bytecodealliance/wasmtime/assets/2720041/048b75b3-c150-4b51-bd3a-c51a430e2d4e)

view this post on Zulip Wasmtime GitHub notifications bot (Mar 09 2024 at 00:47):

yowl commented on issue #7911:

Going to close this now as #8055 exists. Thanks!


Last updated: Oct 23 2024 at 20:03 UTC