It seems to me better to remove breakpoint sites under any memory that you are going to overwrite. The old breakpoints aren't guaranteed to make any sense and, for instance, on x86 could do harm (they could end up in the middle of an instruction in the new TEXT.)
If you want to do this regularly, you should remove the breakpoints and then ask the breakpoint resolver to re-check the new code once it has been written. If for instance you are writing down memory that you have debug info for, then it will reset the breakpoints based on the new symbols for this location. Jim > On Jan 23, 2018, at 8:42 AM, Tatyana Krasnukha via Phabricator via > lldb-commits <lldb-commits@lists.llvm.org> wrote: > > tatyana-krasnukha added a comment. > > Cannot promise that I'll do it (with all tests) quickly, but I'll do. > > One more question: what are the cases when intersection can happen, beside > user forgot to disable it manually? (Will not it be annoying for user to get > breakpoints in unpredictable locations after such situation?) > > > https://reviews.llvm.org/D39967 > > > > _______________________________________________ > lldb-commits mailing list > lldb-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
