jasonmolenda added a comment. In D129814#3654230 <https://reviews.llvm.org/D129814#3654230>, @labath wrote:
> Generally, this makes sense to me, but I do have one question (not > necessarily for Jim). These tests work on (arm) linux, and I am wondering why > is that the case. Could it be related to the fact that lldb-server preserves > the stop reason for threads that are not running? I.e. if we have two threads > hit a breakpoint (or whatever), and then step one of them, then the other > thread will still report a stop_reason=breakpoint. Do you know if this is > supposed to happen (e.g. does debugserver do that)? I'd have to go back and test it to be 100% sure but from the behavior I see on Darwin systems, when we receive a watchpoint hit on two threads at the same time, and instruction-step the first thread, when we ask debugserver for the current stop-reason on thread two, it says there is no reason. The watchpoint exception on the second thread is lost. I could imagine lldb-server behaving differently. (I think when we fetch the mach exceptions for the threads, they've now been delivered, and when we ask the kernel for any pending mach exceptions for the threads a second time -- even if those threads haven't been allowed to run, I think the state is lost, and debugserver didn't save that initial state it received.) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D129814/new/ https://reviews.llvm.org/D129814 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
