labath added a comment. I think the fact that all of our options *must* have a short version is a pretty serious deficiency in our option parsing system. It results in a lot of unintuitive options that nobody uses because they can't guess what they stand for. But anyway, `-x` seems as good as any, as all the good alternatives are already taken.
For testing this, I think the best option would be something similar to the gdb-client suite (test/testcases/functionalities/gdb_remote_client), which allows you to mock the remote end of a connection. It is currently geared toward talking to the gdb server (and not the platform), but as the underlying protocol is the same, I am hoping that it can be repurposed to this use case fairly easily. I am imagining a flow where you create a mock server, configure it to respond appropriately to any packet that lldb issues, and then run e.g. "platform select remote-linux", "platform connect connect://localhost:%d", "platform proces list --all-users". Setting that up is a bit overkill for a simple patch as this one, but as it looks like you're going to be doing a lot of work in this area in the near future, I think it makes sense to set up some testing infrastructure early. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68354/new/ https://reviews.llvm.org/D68354 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
