xusheng6 wrote: > On the testing, lldb sends this qsupported value regardless of what the > remote sends. So there's nothing to do there unless you just repeat the > feature list. There are some tests that look at lldb-server's qsupported > values, but I don't see any for the client lldb. > > You could check we don't crash when seeing swbreak/hwbreak in a stop > response, but it's the same as checking we don't crash on any other unknown > key in there. Since you can't observe any behaviour change from > swbreak/hwbreak, so I don't think that has much value either. > > What you could do is write a test where lldb connects to a mock gdbserver > that claims to be an architecture where the correction to addresses would be > done by a gdb server (GDB's gdbserver I mean). Then via lldb check that the > stopped location is unmodified. You could then run the test with swbreak / > hwbreak / neither of those in the stop info and each time lldb will report > the value unchanged. > > So in the unlikely case that we decided to change how lldb behaves, the test > would fail. `lldb/test/API/functionalities/gdb_remote_client/TestStopPCs.py` > might be a good starting point.
I totally agree with you that the first two cases, even if added, would not provide much value. For the third case, i.e., writing a mock gdbserver, I think that is quite a bit of work -- or do we already have some infra that I can use? By the way, do I always need some unit test change to get a PR accepted? In this particular case I do not see a compelling reason to add a new test, though if this is a LLVM development policy then I will start looking into it. https://github.com/llvm/llvm-project/pull/102873 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
