Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Native DWARF Debugging Workaround #11

Open
ErikMcClure opened this issue Feb 24, 2020 · 1 comment
Open

Native DWARF Debugging Workaround #11

ErikMcClure opened this issue Feb 24, 2020 · 1 comment

Comments

@ErikMcClure
Copy link

As discussed at the February in-person meeting, I have been trying to implement translating WebAssembly DWARF to native DWARF debugging that can be used by a debugger like GDB to accurately step through and display the contents of variables.

This is problematic, because some implementations have relocatable linear memory sections, which means the value in memory after compilation is not an actual pointer. Instead, it is an offset from the linear memory section pointer, which must be looked up. This requires accessing a global variable from a DWARF expression using DW_OP_addr, but LLVM does not seem to allow this.

If it were possible to emit DW_OP_addr, then one could construct a workaround by replacing pointers with structs that have a custom member offset. wasmtime says they have managed to do this, but their debugging code doesn't actually seem to use LLVM to emit DWARF information. If they are bypassing LLVM, it would explain how they were able to use DW_OP_addr, and reinforces the need to update LLVM to support this use-case.

If it is possible to convince LLVM to emit the necessary DWARF expressions, I am eager to know how to achieve this. Otherwise I'd like to open a feature request in LLVM to support emitting them.

@yurydelendik
Copy link

This requires accessing a global variable from a DWARF expression using DW_OP_addr, but LLVM does not seem to allow this.

Accessing a location of a global variable requires VM/Runtime context (at least for wasmtime). It is somewhat similar to TLS in native representation. Shall we treat it as a such? Ideally the memory locations have to resolved in relation to the context as well. In wasmtime, we are counting on the VM context to resolve pointers.

I see there is some of DW_OP_form_tls_address support in LLVM -- it is possible to utilize that.

If it is possible to convince LLVM to emit the necessary DWARF expressions

There is wasm-global <index> in Wasm DWARF for globals locations in DWARF expressions. We need to implement that in LLVM, at least for data locations so they will be properly transformed to native DWARF locations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants