Stream: git-wasmtime

Topic: wasmtime / issue #4393 Add debug symbol transformation fo...

view this post on Zulip Wasmtime GitHub notifications bot (Jul 06 2022 at 18:48):

jeffcharles opened issue #4393:

Feature

Debug symbol transformation for AArch64. That is, when running wasmtime compile -g <path_to_wasm>, wasmtime does not exit with an error message and debug symbols are included in the resulting .cwasm file.

Benefit

It enables developers writing code targeting a Wasm environment to be able to step debug their code in a Wasm environment if they are using Apple Silicon.

Implementation

https://github.com/jeffcharles/wasmtime/pull/1/files. This uses a similar approach to how the symbols are mapped for x86_64. I can open that PR on this repo instead. The contribution guidelines mentioned I should open an issue here first to discuss.

The PR above seems to work for a number of test cases that I've tried.

Alternatives

I'm not sure what the alternatives are.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 11 2022 at 16:19):

akirilov-arm labeled issue #4393:

Feature

Debug symbol transformation for AArch64. That is, when running wasmtime compile -g <path_to_wasm>, wasmtime does not exit with an error message and debug symbols are included in the resulting .cwasm file.

Benefit

It enables developers writing code targeting a Wasm environment to be able to step debug their code in a Wasm environment if they are using Apple Silicon.

Implementation

https://github.com/jeffcharles/wasmtime/pull/1/files. This uses a similar approach to how the symbols are mapped for x86_64. I can open that PR on this repo instead. The contribution guidelines mentioned I should open an issue here first to discuss.

The PR above seems to work for a number of test cases that I've tried.

Alternatives

I'm not sure what the alternatives are.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 11 2022 at 16:19):

akirilov-arm labeled issue #4393:

Feature

Debug symbol transformation for AArch64. That is, when running wasmtime compile -g <path_to_wasm>, wasmtime does not exit with an error message and debug symbols are included in the resulting .cwasm file.

Benefit

It enables developers writing code targeting a Wasm environment to be able to step debug their code in a Wasm environment if they are using Apple Silicon.

Implementation

https://github.com/jeffcharles/wasmtime/pull/1/files. This uses a similar approach to how the symbols are mapped for x86_64. I can open that PR on this repo instead. The contribution guidelines mentioned I should open an issue here first to discuss.

The PR above seems to work for a number of test cases that I've tried.

Alternatives

I'm not sure what the alternatives are.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 11 2022 at 16:19):

akirilov-arm labeled issue #4393:

Feature

Debug symbol transformation for AArch64. That is, when running wasmtime compile -g <path_to_wasm>, wasmtime does not exit with an error message and debug symbols are included in the resulting .cwasm file.

Benefit

It enables developers writing code targeting a Wasm environment to be able to step debug their code in a Wasm environment if they are using Apple Silicon.

Implementation

https://github.com/jeffcharles/wasmtime/pull/1/files. This uses a similar approach to how the symbols are mapped for x86_64. I can open that PR on this repo instead. The contribution guidelines mentioned I should open an issue here first to discuss.

The PR above seems to work for a number of test cases that I've tried.

Alternatives

I'm not sure what the alternatives are.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 11 2022 at 16:19):

akirilov-arm labeled issue #4393:

Feature

Debug symbol transformation for AArch64. That is, when running wasmtime compile -g <path_to_wasm>, wasmtime does not exit with an error message and debug symbols are included in the resulting .cwasm file.

Benefit

It enables developers writing code targeting a Wasm environment to be able to step debug their code in a Wasm environment if they are using Apple Silicon.

Implementation

https://github.com/jeffcharles/wasmtime/pull/1/files. This uses a similar approach to how the symbols are mapped for x86_64. I can open that PR on this repo instead. The contribution guidelines mentioned I should open an issue here first to discuss.

The PR above seems to work for a number of test cases that I've tried.

Alternatives

I'm not sure what the alternatives are.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 15 2022 at 18:40):

akirilov-arm commented on issue #4393:

Have you seen issue #2856? It documents some of the issues with full debugging support on non-x86 platforms (in fact, it subsumes the previous AArch64-specific issue, #1523) and is probably a better place to discuss any details that are not AArch64-specific.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 18 2022 at 14:57):

jeffcharles commented on issue #4393:

I had not seen that issue. I can take a look at those details.

Even without changes to the debug crate though, given my change, I'm currently able to get a reasonable debugging experience on AArch64 as opposed to an error message with the status quo.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 18 2022 at 20:49):

jameysharp commented on issue #4393:

I see the PR just makes aarch64 do exactly what x64 and s390x already do. I don't know much yet about Cranelift's target backends, but it seems plausible to me that inst::unwind::systemv::map_reg would be the right choice for aarch64 as well. @akirilov-arm, is there any reason not to merge this?

Also, maybe we should edit the contributor guidelines to say that if it's easier to explain your issue by just opening a pull request showing what you want changed, then you don't need to open an issue first? Anyway I'd say go ahead and open a PR here with your proposed changes.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 19 2022 at 13:11):

akirilov-arm commented on issue #4393:

@akirilov-arm, is there any reason not to merge this?

I don't know, usually I don't look at PRs that have not been opened in this repository. From a cursory glance it looks OK, but I am not really familiar with that part of the code.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 19 2022 at 18:30):

jeffcharles commented on issue #4393:

I've opened a PR at #4468.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 19 2022 at 19:50):

jameysharp commented on issue #4393:

Merged, thank you!

view this post on Zulip Wasmtime GitHub notifications bot (Jul 19 2022 at 19:50):

jameysharp closed issue #4393:

Feature

Debug symbol transformation for AArch64. That is, when running wasmtime compile -g <path_to_wasm>, wasmtime does not exit with an error message and debug symbols are included in the resulting .cwasm file.

Benefit

It enables developers writing code targeting a Wasm environment to be able to step debug their code in a Wasm environment if they are using Apple Silicon.

Implementation

https://github.com/jeffcharles/wasmtime/pull/1/files. This uses a similar approach to how the symbols are mapped for x86_64. I can open that PR on this repo instead. The contribution guidelines mentioned I should open an issue here first to discuss.

The PR above seems to work for a number of test cases that I've tried.

Alternatives

I'm not sure what the alternatives are.

Last updated: Oct 23 2024 at 20:03 UTC