jingham added a comment. In D129814#3654368 <https://reviews.llvm.org/D129814#3654368>, @labath wrote:
> In D129814#3654276 <https://reviews.llvm.org/D129814#3654276>, @jasonmolenda > wrote: > >> 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.) > > Yes, that sounds plausible. It lldb-server (on linux) it happens differently > because we store each stop reason inside the thread object, and since we can > control each thread independently, there's no reason to touch it if we're not > running the thread. Although it also wouldn't be hard to clear in on every > resume. > > So which one of these behaviors would you say is the correct one? Darwin has always worked in such a way that by the time it stops for an exception it will have given other threads enough chance to run that if they were likely to, other threads will hit the exception before the first exception is delivered to lldb. In gdb we tried to hide that fact by only publishing one exception, but that was awkward since you when you tried to resume to do some piece of work, you'd immediately stop again without getting to run. That just lead to confusing interactions (and was a little harder to deal with in the debugger as well). I think it's clearer to stop and see 5 threads have hit your breakpoint, then decide what to do, than to have one breakpoint reported then when you "continue" immediately turn around and get another without anybody really seeming to make progress, rinse, repeat... 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
