labath accepted this revision. labath added a comment. This revision is now accepted and ready to land. Herald added a subscriber: dexonsmith.
LGTM, since this seems to be the best we can do given the current netbsd behavior. However, I'd like to repeat what I said on the IRC, that I consider this behavior of netbsd to be unreasonable. Serializing signals delivery seems nice at a first glance, but when those signals reflect events which are "trapped" (== caught only after the relevant thing has happened), as is the case with watchpoints on x86, things just start getting weird. This means that if we get a "concurrent" watchpoint hits, we will only report the one of the watchpoint hits, but the entire state of the program will be already in the "post-hit" state for both watchpoints (the memory will contain the new value, PC will point after the trapping instruction, etc.). I think this state can be very confusing to the user, particularly if he decides to run an expression in this state (to figure out what happened?) and then this expression is interrupted by the delayed delivery of the second watchpoint signal. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D70025/new/ https://reviews.llvm.org/D70025 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
