JDevlieghere wrote: > @JDevlieghere Thank you! > > I will remove the code that handles DW_OP_WASM_location as you suggest.
Given we don't have a good solution for stacked commits, you don't necessarily need to remove it here, and rebase it once the other PR has been merged. > For what concerns testing, I took a very quick look at > `GdbRemoteTestCaseBase` and if I am not wrong, it works by spawning an > inferior processor attaching to an inferior process to debug. But it relies > on the fact that it can use lldb-server, which implements the server-side of > the gdb-remote protocol. But here we need to attach to a Wasm engine, and > obviously, we cannot implement a Wasm engine as part of the LLDB test code. > Maybe we should implement a process that mocks the gdb-stub logic for a Wasm > engine? Is there anything we could reuse in the LLDB test framework? You're right that there are tests that work like that and indeed, that wouldn't work for this. If you look for tests that use the `GdbRemoteTestCaseBase` you can basically spoof the other end of the GDB remote connection. You can have it respond to packets the way your real GDB stub would. You can make it as advanced or simple as you want. There's a bunch of examples in `test/API/functionalities/gdb_remote_client`. What I would do is debug a simple program using the real GDB stub and look at the gdb packet log in lldb to give you an idea what the server responds. Then I would try to mimic the debug session in the tests and implement responses from the mock server. You want to keep things as small as possible so you don't want to avoid just copy/pasting full responses (they likely wouldn't work anyway) but the real packets can serve as inspiration. https://github.com/llvm/llvm-project/pull/77949 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
