clayborg added a comment. In https://reviews.llvm.org/D39967#984989, @tatyana-krasnukha wrote:
> > Does this functionality really belong in the client? In case of memory > > reads, it's the server who patches out the breakpoint opcodes > > (NativeProcessProtocol::ReadMemoryWithoutTrap). I think it would make sense > > to do this in the same place. > > Will not work for gdb-remote mode, other servers treat this just as a block > of memory. > I might be wrong, but gdb inserts a breakpoint right before execution of > instruction range, containing this breakpoint, and removes right after stop. That is why GDB doesn't do well if you set thousands of breakpoints. It makes debugging so slow and painful that it is useless. With LLDB we have the ability to set many breakpoints and still be able to debug quite well. LLDB is being used for program guided optimizations where we set a breakpoint on every function in a shared library and as each breakpoint location gets hit, we disable it. So while the GDB method makes things easier, it is quite inefficient when it is so easy to work around by knowing how to work around software breakpoints. So I like the way LLDB does it over GDB. Debugging on remote devices (like and Apple Watch) is quite slow to begin with and every packet counts. If we even set 20 breakpoints, that can easily add over 1 second per stop and 1 second per resume due to packets being limited to 20-40 packets per second. > What is the need to save breakpoints in general? Because when memory is > overwritten, breakpoints may have no sense anymore at their locations... https://reviews.llvm.org/D39967 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
