labath added a comment. In https://reviews.llvm.org/D54221#1290638, @JDevlieghere wrote:
> In https://reviews.llvm.org/D54221#1290572, @labath wrote: > > > I recall something about linux on arm having a magic unmodifiable (even by > > ptrace) page of memory, so this could be useful there too. However, it's > > not clear to me how a user is going to figure out that he needs to enable > > this setting. Would it make sense to automatically try setting a hardware > > breakpoint if software breakpoint fails? > > > My main concern would be that hardware breakpoints are a limited resource and > not something we want to make transparent to the user, because it's only a > matter of time before it fails. That is true, but on the other hand, you would only use hw breakpoints on those pieces of memory where you really need to instead of everywhere, which means (at least for the use case I have in mind) it be used very rarely. Of course, we would have to be careful do differentiate between reasons why setting a sw breakpoint failed (is it because the memory is RO, or some other reason like there is no memory at that address). However, with this approach, it's still not clear to me how will the user know that he has to enable this setting? Will he get some sort of an error pointing here when the sw breakpoint fails? Or will you just enable this setting by default for targets where you know this is an issue? https://reviews.llvm.org/D54221 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
