diff options
| author | Jonas Devlieghere <jonas@devlieghere.com> | 2025-10-13 10:20:40 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-10-13 10:20:40 -0700 |
| commit | 14a7c8a741678766953fb5c14acec3fe301f48e1 (patch) | |
| tree | 79313e0ecd70b8c1e5b7e62cce5a6f82a7afbdcb /llvm/lib/Support/SourceMgr.cpp | |
| parent | fc22b58c25963ece6b041cadbdc931c2338955e4 (diff) | |
| download | llvm-14a7c8a741678766953fb5c14acec3fe301f48e1.zip llvm-14a7c8a741678766953fb5c14acec3fe301f48e1.tar.gz llvm-14a7c8a741678766953fb5c14acec3fe301f48e1.tar.bz2 | |
[lldb] Use the correct Wasm register context (#162942)
When implementing the WebAssembly Process Plugin, I initially added
WasmGDBRemoteRegisterContext as a placeholder in the UnwindWasm TU.
After implementing RegisterContextWasm (#151056), I forgot to switch
over to the new implementation. This meant we were using the wrong
register context for all frames, except frame 0. The register context
deals with the virtual registers, so this only becomes an issue when
trying to evaluate a `DW_OP_WASM_location`, which is why this went
unnoticed.
This PR removes the WasmGDBRemoteRegisterContext placeholder and updates
UnwindWasm to use RegisterContextWasm instead for all frames.
In terms of testing, I considered updating TestWasm but that would
require adding even more state to the already complicated GDB stub. This
doesn't scale and my focus over the next weeks/months will be coming up
with a comprehensive testing strategy that involves running (a subset of
the) API tests under a Wasm runtime, which will cover this and much
more.
rdar://159297244
Diffstat (limited to 'llvm/lib/Support/SourceMgr.cpp')
0 files changed, 0 insertions, 0 deletions