Cranelift ARM64 / AArch64 backend: support debug info #1523
Labels
cranelift:area:aarch64
Issues related to AArch64 backend.
cranelift
Issues related to the Cranelift code generator
Comments
Subscribe to Label Actioncc @bnjbvr
This issue or pull request has been labeled: "cranelift"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Apr 16, 2020
This commit enhances our CI with an AArch64 builder. Currently we have no physical hardware to run on so for now we run all tests in an emulator. The AArch64 build is cross-compiled from x86_64 from Linux. Tests all happen in release mode with a recent version of QEMU (recent version because it's so much faster, and in release mode because debug mode tests take quite a long time in an emulator). The goal here was not to get all tests passing on CI, but rather to get AArch64 running on CI and get it green at the same time. To achieve that goal many tests are now ignored on aarch64 platforms. Many tests fail due to unimplemented functionality in the aarch64 backend (bytecodealliance#1521), and all wasmtime tests involving compilation are also disabled due to panicking attempting to generate generate instruction offset information for trap symbolication (bytecodealliance#1523). Despite this, though, all Cranelift tests and other wasmtime tests should be runnin on AArch64 through QEMU with this PR. Additionally we'll have an AArch64 binary release of Wasmtime for Linux, although it won't be too useful just yet since it will panic on almost all wasm modules.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Apr 16, 2020
This commit enhances our CI with an AArch64 builder. Currently we have no physical hardware to run on so for now we run all tests in an emulator. The AArch64 build is cross-compiled from x86_64 from Linux. Tests all happen in release mode with a recent version of QEMU (recent version because it's so much faster, and in release mode because debug mode tests take quite a long time in an emulator). The goal here was not to get all tests passing on CI, but rather to get AArch64 running on CI and get it green at the same time. To achieve that goal many tests are now ignored on aarch64 platforms. Many tests fail due to unimplemented functionality in the aarch64 backend (bytecodealliance#1521), and all wasmtime tests involving compilation are also disabled due to panicking attempting to generate generate instruction offset information for trap symbolication (bytecodealliance#1523). Despite this, though, all Cranelift tests and other wasmtime tests should be runnin on AArch64 through QEMU with this PR. Additionally we'll have an AArch64 binary release of Wasmtime for Linux, although it won't be too useful just yet since it will panic on almost all wasm modules.
|
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
added a commit
to cfallin/wasmtime
that referenced
this issue
Apr 17, 2020
…ess map. The current build of wasmtime on aarch64 panics immediately because the debug infrastructure constructs an address-to-instruction map unconditionally now, and the new backend does not yet support debug info generally (bytecodealliance#1523). In this particular case, the address-map construction consults the encoding info, which is not implemented by the new backend and causes the panic. This fix simply avoids generating per-instruction entries in the address map; it at least gets us going until we plumb SourceLocs all the way through the new pipeline.
alexcrichton
pushed a commit
that referenced
this issue
Apr 17, 2020
…ess map. (#1541) The current build of wasmtime on aarch64 panics immediately because the debug infrastructure constructs an address-to-instruction map unconditionally now, and the new backend does not yet support debug info generally (#1523). In this particular case, the address-map construction consults the encoding info, which is not implemented by the new backend and causes the panic. This fix simply avoids generating per-instruction entries in the address map; it at least gets us going until we plumb SourceLocs all the way through the new pipeline.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Apr 17, 2020
This commit enhances our CI with an AArch64 builder. Currently we have no physical hardware to run on so for now we run all tests in an emulator. The AArch64 build is cross-compiled from x86_64 from Linux. Tests all happen in release mode with a recent version of QEMU (recent version because it's so much faster, and in release mode because debug mode tests take quite a long time in an emulator). The goal here was not to get all tests passing on CI, but rather to get AArch64 running on CI and get it green at the same time. To achieve that goal many tests are now ignored on aarch64 platforms. Many tests fail due to unimplemented functionality in the aarch64 backend (bytecodealliance#1521), and all wasmtime tests involving compilation are also disabled due to panicking attempting to generate generate instruction offset information for trap symbolication (bytecodealliance#1523). Despite this, though, all Cranelift tests and other wasmtime tests should be runnin on AArch64 through QEMU with this PR. Additionally we'll have an AArch64 binary release of Wasmtime for Linux, although it won't be too useful just yet since it will panic on almost all wasm modules.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Apr 20, 2020
This commit enhances our CI with an AArch64 builder. Currently we have no physical hardware to run on so for now we run all tests in an emulator. The AArch64 build is cross-compiled from x86_64 from Linux. Tests all happen in release mode with a recent version of QEMU (recent version because it's so much faster, and in release mode because debug mode tests take quite a long time in an emulator). The goal here was not to get all tests passing on CI, but rather to get AArch64 running on CI and get it green at the same time. To achieve that goal many tests are now ignored on aarch64 platforms. Many tests fail due to unimplemented functionality in the aarch64 backend (bytecodealliance#1521), and all wasmtime tests involving compilation are also disabled due to panicking attempting to generate generate instruction offset information for trap symbolication (bytecodealliance#1523). Despite this, though, all Cranelift tests and other wasmtime tests should be runnin on AArch64 through QEMU with this PR. Additionally we'll have an AArch64 binary release of Wasmtime for Linux, although it won't be too useful just yet since it will panic on almost all wasm modules.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Apr 21, 2020
This commit enhances our CI with an AArch64 builder. Currently we have no physical hardware to run on so for now we run all tests in an emulator. The AArch64 build is cross-compiled from x86_64 from Linux. Tests all happen in release mode with a recent version of QEMU (recent version because it's so much faster, and in release mode because debug mode tests take quite a long time in an emulator). The goal here was not to get all tests passing on CI, but rather to get AArch64 running on CI and get it green at the same time. To achieve that goal many tests are now ignored on aarch64 platforms. Many tests fail due to unimplemented functionality in the aarch64 backend (bytecodealliance#1521), and all wasmtime tests involving compilation are also disabled due to panicking attempting to generate generate instruction offset information for trap symbolication (bytecodealliance#1523). Despite this, though, all Cranelift tests and other wasmtime tests should be runnin on AArch64 through QEMU with this PR. Additionally we'll have an AArch64 binary release of Wasmtime for Linux, although it won't be too useful just yet since it will panic on almost all wasm modules.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Apr 22, 2020
This commit enhances our CI with an AArch64 builder. Currently we have no physical hardware to run on so for now we run all tests in an emulator. The AArch64 build is cross-compiled from x86_64 from Linux. Tests all happen in release mode with a recent version of QEMU (recent version because it's so much faster, and in release mode because debug mode tests take quite a long time in an emulator). The goal here was not to get all tests passing on CI, but rather to get AArch64 running on CI and get it green at the same time. To achieve that goal many tests are now ignored on aarch64 platforms. Many tests fail due to unimplemented functionality in the aarch64 backend (bytecodealliance#1521), and all wasmtime tests involving compilation are also disabled due to panicking attempting to generate generate instruction offset information for trap symbolication (bytecodealliance#1523). Despite this, though, all Cranelift tests and other wasmtime tests should be runnin on AArch64 through QEMU with this PR. Additionally we'll have an AArch64 binary release of Wasmtime for Linux, although it won't be too useful just yet since it will panic on almost all wasm modules.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Apr 22, 2020
This commit enhances our CI with an AArch64 builder. Currently we have no physical hardware to run on so for now we run all tests in an emulator. The AArch64 build is cross-compiled from x86_64 from Linux. Tests all happen in release mode with a recent version of QEMU (recent version because it's so much faster, and in release mode because debug mode tests take quite a long time in an emulator). The goal here was not to get all tests passing on CI, but rather to get AArch64 running on CI and get it green at the same time. To achieve that goal many tests are now ignored on aarch64 platforms. Many tests fail due to unimplemented functionality in the aarch64 backend (bytecodealliance#1521), and all wasmtime tests involving compilation are also disabled due to panicking attempting to generate generate instruction offset information for trap symbolication (bytecodealliance#1523). Despite this, though, all Cranelift tests and other wasmtime tests should be runnin on AArch64 through QEMU with this PR. Additionally we'll have an AArch64 binary release of Wasmtime for Linux, although it won't be too useful just yet since it will panic on almost all wasm modules.
alexcrichton
added a commit
that referenced
this issue
Apr 22, 2020
* Add AArch64 tests to CI This commit enhances our CI with an AArch64 builder. Currently we have no physical hardware to run on so for now we run all tests in an emulator. The AArch64 build is cross-compiled from x86_64 from Linux. Tests all happen in release mode with a recent version of QEMU (recent version because it's so much faster, and in release mode because debug mode tests take quite a long time in an emulator). The goal here was not to get all tests passing on CI, but rather to get AArch64 running on CI and get it green at the same time. To achieve that goal many tests are now ignored on aarch64 platforms. Many tests fail due to unimplemented functionality in the aarch64 backend (#1521), and all wasmtime tests involving compilation are also disabled due to panicking attempting to generate generate instruction offset information for trap symbolication (#1523). Despite this, though, all Cranelift tests and other wasmtime tests should be runnin on AArch64 through QEMU with this PR. Additionally we'll have an AArch64 binary release of Wasmtime for Linux, although it won't be too useful just yet since it will panic on almost all wasm modules. * Review comments
|
Is this still an issue that one can't get debug info in the aarch64 backend (but works with x64 backend)? |
|
@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.) |
|
(To be clear, the debuginfo stuff I'm working on is for both |
|
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. |
|
@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. |
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. |
|
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. |
|
I just noticed that some of the issues had been mentioned in issue #2856. |
|
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). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
The text was updated successfully, but these errors were encountered: