uweigand opened Issue #2856:
Feature
Support debugging JITted WebAssembly code on non-x86 platforms.
Benefit
Currently, the debug crate only supports x86. All other platforms should be supported as well.
Implementation
There are a number of places that currently prevent the debug crate from supporting non-x86 platforms:
- Explicit architecture check in lib.rs:
match header.e_machine.get(e) { EM_X86_64 => (), machine => { bail!("Unsupported ELF target machine: {:x}", machine); } }
(This should just go away, I think.)
- Explicit X86 assumptions in transform/expression.rs:
writer.write_op_breg(X86_64::RBP.0)?; writer.write_sleb128(ss_offset as i64 + X86_64_STACK_OFFSET)?;
(This is only used for old-style back-ends and can probably go away soon.)
writer.write_op_breg(X86_64::RSP.0)?;
(This should probably use the register mapper that unwinder code also uses.)
Various little-endian assumptions accessing ELF files and WebAssembly memory
(See https://github.com/bytecodealliance/wasmtime/pull/2854 for details.)Additional endian issues (not solved by the PR above) in creating DWARF expressions
Current code in transform/expression.rs simply copies portions of the incoming WebAssembly DWARF expressions directly into the native DWARF output. This is not correct in case the native architecture is big-endian. Fortunately, the byte code for many DWARF expressions is not endian-sensitive, so I can actually debug simple applications even so. But to be fully correct, those portions of DWARF bytecode that _are_ endian-sensitive will need to be handled here somehow.
uweigand commented on Issue #2856:
Hi @cfallin, this is the topic we talked about recently. I just wanted to open this issue to document all the places I've found where there is currently X86-specific code in the debug crate.
Last updated: Dec 23 2024 at 12:05 UTC