[PATCH] D69807: [WebAssembly] Track frame/stack pointer local for debug information

Yury Delendik via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 6 11:24:30 PST 2019


yurydelendik added a comment.

In D69807#1734845 <https://reviews.llvm.org/D69807#1734845>, @dschuff wrote:

> we'd need to ensure that the frame base stays in the designated local for the whole function, correct? i.e. we'd have to ensure it never gets stackified, which it currently could, right?


Ideally, that's correct. Though we need to take in account Philosophy behind LLVM debugging information <https://llvm.org/docs/SourceLevelDebugging.html#philosophy-behind-llvm-debugging-information> . If producing a "stable" frame base location is a trade-off for producing an optimized code, the latter has to be favored.

> Come to think of it, do we know that the CFA is always correct in that case ? IIUC if SP gets stackified, we'd need to emit CFA definition instructions to ensure that the debugger could follow it from the local to the stack, possibly to another local, etc.

Right, the moving/spilling (between registers) is not handled as this moment. :/ TODO

> How are you handling this with wasmtime right now?

wasmtime, when transforms wasm DWARF into "native" DWARF, is able to process DW_AT_frame_base as a list that can define noncontinuous/different frame base locations for a single function. It is worth to note that during transform/compilation WebAssembly FP/SP abstraction will disappear as result of JIT/AOT compiler's work -- the wasm DWARF DW_AT_frame_base will be inlined into "native" DWARF expressions as transformed operators to match native instructions.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69807/new/

https://reviews.llvm.org/D69807





More information about the llvm-commits mailing list