Skip to content
This repository has been archived by the owner on Feb 5, 2019. It is now read-only.

[WIP] Encode WebAssembly specific locations in DBG_VALUEs and DW_AT_frame_base #134

Merged

Conversation

yurydelendik
Copy link

@yurydelendik yurydelendik commented Jan 11, 2019

(Based on Add DBG_VALUE with local operands location in WebAssemblyExplicitLocals pass):

Extends DWARF expression larguage to express locals/globals locations. (via
target-index operands atm)

  • The WebAssemblyExplicitLocals can replace virtual registers to target-index operand type at the time when WebAssembly backend introduces {get,set,tee}_local instead of corresponding virtual registers.

  • The subroutine frame base address can contain WebAssembly location (e.g. local)

@yurydelendik
Copy link
Author

/cc @alexcrichton @fitzgen

@alexcrichton
Copy link
Member

Thanks @yurydelendik!

For some more information if others are following along, this is an experimental patch set for LLVM to emit accurate DWARF information for the WebAssembly target. Currently LLVM's offerings of DWARF on wasm are slightly lacking and slightly incorrect. This is not going upstream first because we're developing it on Rust to later get it into upstream. It looks like we'll want solid proofs of concept before sending upstream.

This is a best-effort basis merge. We'll reserve the right to back this out at any time, for example if it causes regressions. If we rebase LLVM we likely won't pick up these patches again because they likely won't apply cleanly. In that case though we'll let you know @yurydelendik! It's just to say, though, that rust nightly cannot rely on this being available 100% of the time.

It's thought that this is a very low-risk patch to merge. It only affects the WebAssembly target and even then only affects part of WebAssembly that no one is really using, the DWARF debug information.

If anyone's got further questions though please let me know!

@alexcrichton alexcrichton merged commit b490116 into rust-lang:rust-llvm-release-8-0-0-v2 Jan 14, 2019
@cuviper
Copy link
Member

cuviper commented Jan 14, 2019

If we rebase LLVM we likely won't pick up these patches again because they likely won't apply cleanly.

Should I try to include it in the rebase to llvm-project (the monorepo) that I'm working on right now? Or is that already unlikely to apply cleanly? @yurydelendik, does the "Based on" patch have the same functionality on current trunk?

@yurydelendik
Copy link
Author

yurydelendik commented Jan 14, 2019

@yurydelendik, does the "Based on" patch have the same functionality on current trunk?

The upstream patches under review and discussions at the LLVM side. I'll try to address reviews in both places and/or rebase accordingly (in not landed side). That said, they can be not-in-sync at certain times.

@alexcrichton
Copy link
Member

@yurydelendik oh what @cuviper means is that we're in the process of switching our set of LLVM submodules to a LLVM monorepo. LLVM is switching soon to a monorepo and @cuviper is preparing a fork for us to use.

@yurydelendik mind sending these patches to that fork when it's ready? @cuviper I think it's fine to go ahead with what you're doing and we can apply these patches after-the-fact

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

Successfully merging this pull request may close these issues.

3 participants