Stream: git-wasmtime

Topic: wasmtime / issue #1523 Cranelift ARM64 / AArch64 backend:...


view this post on Zulip Wasmtime GitHub notifications bot (Sep 13 2021 at 12:18):

akirilov-arm commented on issue #1523:

@cfallin What is the status of this issue? Unwinding works now, but what about some of the other functionality you mention (e.g. map Wasm locals to registers/stack slots)? I suppose the latter would not be implemented in AArch64-specific code anyway, so we should probably rephrase the issue a bit.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 13 2021 at 12:26):

bjorn3 commented on issue #1523:

I suppose the latter would not be implemented in AArch64-specific code anyway

All debuginfo generation requires code in the backend for the respective architecture to keep the mapping between the clif level input and the machine code level output for the respective debuginfo constructs. At least for value debuginfo the backend part is already implemented for AArch64 though I think.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 13 2021 at 16:41):

cfallin commented on issue #1523:

The general debuginfo support -- passing the correspondences through to the codegen and then computing the metadata -- works for new backends generally, as I had built that out and tested it on x86-64. However, IIRC, there are some x86-isms in the DWARF support code in the debug crate and so it probably needs a bit more work to fully connect the dots on aarch64. I don't have time to look into this at the moment, but would be happy to review PRs if someone else does.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 04 2021 at 11:57):

akirilov-arm commented on issue #1523:

I just noticed that some of the issues had been mentioned in issue #2856.

view this post on Zulip Wasmtime GitHub notifications bot (May 04 2022 at 22:33):

cfallin commented on issue #1523:

I'm doing some issue gardening and I will go ahead and close this in favor of #2856, which subsumes this (the issue is really that some of the DWARF-handling is x86-specific).

view this post on Zulip Wasmtime GitHub notifications bot (May 04 2022 at 22:33):

cfallin closed 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


Last updated: Nov 22 2024 at 16:03 UTC