cfallin opened Issue #1523:
We need to propagate debug information through the new compilation pipeline in order to support several use-cases. For example,
wasmtime
needs 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
alexcrichton labeled Issue #1523:
We need to propagate debug information through the new compilation pipeline in order to support several use-cases. For example,
wasmtime
needs 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
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>
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).
cfallin labeled Issue #1523:
We need to propagate debug information through the new compilation pipeline in order to support several use-cases. For example,
wasmtime
needs 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
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)?
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.)
cfallin commented on Issue #1523:
(To be clear, the debuginfo stuff I'm working on is for both
MachInst
backends, not just aarch64.)
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: Dec 23 2024 at 12:05 UTC