[Lldb-commits] [lldb] [lldb] Claim to support swbreak and hwbreak packets when debugging a gdbremote (PR #102873)

[via lldb-commits]

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