jingham requested changes to this revision. jingham added a comment. This revision now requires changes to proceed.
IIUC, what you are doing here is when lldb-server gets a "step instruction" request that would step into one of these atomic regions, it sets a bunch of breakpoints on it's end (not telling the LLDB stepping machinery what is going on), and continues till it hits one of these. Then it will end up not where the thread plans expect it to at all, but presumably they will just have to cope? That doesn't seem the right way to go about this, since it means that you can't do any reasoning based on what the stepping machinery was trying to achieve. It would be better to wire this into the ThreadPlanStepRange's AddNextRangeBreakpoint. That's where we are doing "I want to make the next step within this range". Usually we just run to the next branch, setting breakpoints to do that. Or we single step if we are on a branch. But there's no reason that's the only thing we can do here. This would be much better because we could decide whether to do this (because we are source line stepping) or not (because we are instruction stepping) etc. We could also do things like warn if the compiler accidentally puts a line break in the middle of an atomic region. This would make the kind of considerations Tamas mentioned possible, whereas if you do things behind the stepping machinery's back, we're can't do this, and will probably end up confused in other ways as well. 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
