tberghammer added a comment. In http://reviews.llvm.org/D17535#360519, @bhushan wrote:
> In MIPS, we can not put a breakpoint in middle of an atomic sequence. > If we do so (and that breakpoint is hit) then continuing from breakpoint > address will cause "SC" to fail due to a breakpoint exception. > SC fails when there’s been any exception serviced since the LL. This will > then become a "never ending" sequence. I agree that we shouldn't put a breakpoint in the middle of an atomic sequence (same is true on arm/aarch64) but your patch isn't preventing LLDB from doing it. I think what Jim and I are asking for is a solution where the atomic sequences are handled on host side so we either ensure that we don't set a breakpoint inside them or gracefully handle the continuing from them (with removing the breakpoint and only putting it back after the "SC" succeeded in the next iteration). > Similarly when doing assembly level debugging of an atomic sequence if we > step only 1 instruction (as we are debugging assembly code) > we will end up putting breakpoint on next instruction (within atomic > sequence) and will cause "SC" to fail because of reason mentioned above. I expect that if somebody debug some atomic instruction sequences at assemply level then they will know about the behavior of LL and SC and they will work around the limitation with putting a breakpoint after SC to exit the loop around the atomic sequence. For me as a user it would be worrying if an instruction single step steps more then 1 actual instruction. Additionally we can add a new step command what steps out from an atomic sequence if there is user need for it. > That means an atomic sequence, starting with LL and ending with SC needs to > be treated as a "single instruction block". Agree, but I think we should do it on the host side. Repository: rL LLVM http://reviews.llvm.org/D17535 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
