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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
