Wasmtime GitHub notifications bot (Apr 16 2020 at 18:13): Wasmtime GitHub notifications bot (Apr 16 2020 at 18:13):cfallin opened Issue #1523:
We need to propagate debug information through the new compilation pipeline in order to support several use-cases. For example,
wasmtimeneeds this information to build a map from machine-code offsets to wasm bytecode offsets. Other use-cases may want to e.g. emit DWARF debug info in an AOT-compiled object output file.Issue raised by @alexcrichton in the wasmtime context
cc @julian-seward1, @bnjbvr
Wasmtime GitHub notifications bot (Apr 16 2020 at 20:11):alexcrichton labeled Issue #1523:
We need to propagate debug information through the new compilation pipeline in order to support several use-cases. For example,
wasmtimeneeds this information to build a map from machine-code offsets to wasm bytecode offsets. Other use-cases may want to e.g. emit DWARF debug info in an AOT-compiled object output file.Issue raised by @alexcrichton in the wasmtime context
cc @julian-seward1, @bnjbvr
Wasmtime GitHub notifications bot (Apr 16 2020 at 20:11):github-actions[bot] commented on Issue #1523:
Subscribe to Label Action
cc @bnjbvr
<details>
This issue or pull request has been labeled: "cranelift"Thus the following users have been cc'd because of the following labels:
- bnjbvr: cranelift
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
Wasmtime GitHub notifications bot (Apr 17 2020 at 07:35):bnjbvr commented on Issue #1523:
This seems sensible to do, at least for debug information. This was also required for Spidermonkey before using the regular sinks (see also #1453), so there's also the possibility here to add new sinks abstractions to handle this (if it is for every single instruction, this might be high overhead, though).
Wasmtime GitHub notifications bot (Apr 18 2020 at 00:21):cfallin labeled Issue #1523:
We need to propagate debug information through the new compilation pipeline in order to support several use-cases. For example,
wasmtimeneeds this information to build a map from machine-code offsets to wasm bytecode offsets. Other use-cases may want to e.g. emit DWARF debug info in an AOT-compiled object output file.Issue raised by @alexcrichton in the wasmtime context
cc @julian-seward1, @bnjbvr
Wasmtime GitHub notifications bot (Dec 18 2020 at 22:21):repi commented on Issue #1523:
Is this still an issue that one can't get debug info in the aarch64 backend (but works with x64 backend)?
Wasmtime GitHub notifications bot (Dec 18 2020 at 22:24):cfallin commented on Issue #1523:
@repi I'm actually working on this as we speak :-)
There is partial unwind-info generation; this is (IIRC) enough for libunwind to traverse frames on the stack. But there's no DWARF info at the level that would (e.g.) map Wasm locals to registers/stack slots.
(It's a little tricky as it requires tracing the values through lowering and regalloc but there's a solution that should work involving marker instructions and a little post-lowering analysis.)
Wasmtime GitHub notifications bot (Dec 18 2020 at 22:25):cfallin commented on Issue #1523:
(To be clear, the debuginfo stuff I'm working on is for both
MachInstbackends, not just aarch64.)
Wasmtime GitHub notifications bot (Dec 18 2020 at 23:05):repi commented on Issue #1523:
Ah I see, thanks for the clarification! For our own use cases stack traces was the most critical, but general DWARF debug info will be great.
Last updated: Oct 23 2024 at 20:03 UTC