jasonmolenda wrote: I think the tl;dr on this is that mixing eager breakpoints and delayed breakpoints can lead to chronological mistakes and bugs like these. I wonder if our solutions might look, generally, like
1. If we have an eager breakpoint, and there are _any_ enqueued delayed breakpoints, send the delayed breakpoints before we process the eager breakpoint. 2. If we have an eager breakpoint, look at the addresses of the enqueued delayed breakpoints, and if they are a match, send the delayed breakpoints before we process the eager breakpoint. 3. Try to distinguish between a user-initiated by-address breakpoint (which may be at the wrong address, and fail) versus an lldb-initiated by-address breakpoint (which lldb is awesome so surely it is right and can be delayed, even if Jim isn't happy about it). Right now when we have an eager breakpoint, we are sending two breakpoint requests: The eager-breakpoint _right now_, and then when we start execution, any delayed breakpoints in a multi-breakpoint packet. If we do (1), we're still sending two breakpoint requests, it's not any actual performance loss. Unless someone does an expression (forcing delayed breakpoints to be sent, then the eager breakpoint), THEN creates a new breakpoint (enqueuing a new delayed breakpoint) which gets sent when we resume. Maybe that's the right approach, because it's the simplest and doesn't try to be fancier. We simply don't allow delayed breakpoints to exist when doing an eager breakpoint. And if we find we are losing performance in common cases by this approach, we might need to revisit it? https://github.com/llvm/llvm-project/pull/192971 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
