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

[via lldb-commits]

xusheng6 wrote:

> > > Just to be clear, if I'm understanding the packet we'll be getting back, we have no indication that we hit the breakpoint, we only show that we are stopped at an address which has a breakpoint. Current lldb stepping behavior will work -- because the rule is, when we stop at a breakpoint address, we will say we hit the breakpoint. I am refining a patch #96260 which changes this behavior -- we handle "instruction stepped / stopped at a breakpoint" differently than "hit a breakpoint". I worry this difference will be lost with a stub that reports `swbreak`/`hwbreak`, stepping won't work correctly, and we won't capture it in the testsuite or on any of our CI bots.
> > 
> > 
> > My work mainly concerns the case when lldb is connected to a gdbserver, and as far as I can tell, gdbserver does not send a `reason:breakpoint` packet at all. Maybe lldb-server sends it?
> 
> Yes, it does.
> 
> > Also, I do not think lldb itself is adjusting the PC -- I think lldb-server does it, and that is also the reason why my PR did not need to alter the lldb behavior at all. lldb always expects the remote to have adjusted the PC if necessary, and it just uses whatever value that is reported
> 
> That is true, but I believe Jason is saying something slightly different. Currently you are able to use lldb+gdbserver because lldb treats a stop as a breakpoint hit every time we stop and the PC value is equal to one of the breakpoints. Jason's [patch](https://github.com/llvm/llvm-project/pull/96260) will change that and have lldb report a breakpoint hit only if it server tells it that was the reason for the stop. lldb-server does that (`reason:breakpoint`), and everything will work fine, but that will most likely break your use case.
> 
> To (preemtively) fix that, you should probably change lldb to recognize the gdb response (`swbreak`) and treat it the same way as the one from lldb-server. Ideally, you should also add a test to make sure this works (and stays working) -- for that, you could probably extend the test you added here to check that lldb reports the correct stop reason.

Oh I see your point now, and I also see the lldb is handling a `reason:xxxx` packet from the lldb-server. In this sense, I think it is fair to treat "swbreak/hwbreak" in the same way as "reason:breakpoint".

@jasonmolenda do you think you can handle this along with your patch, or you think I should do something for it preemptively as suggested by [labath](https://github.com/labath)? I personally prefer the former case because I am quite new to the lldb code base 

https://github.com/llvm/llvm-project/pull/102873