jingham requested changes to this revision. jingham added a comment. This revision now requires changes to proceed.
The restoration of the stop reason works for the most part. For instance, when we call a user expression the stop reason is correctly restored. This was done by saving and restoring the stop info. There's one other little two-step you have to do to produce the "cooked" stop reason. For instance, if you stop because of a breakpoint hit that completed a "step-out" plan, you have to check the completed plan stack to figure out what the user visible stop reason was. But before Boris' change the state of the completed plan stack wasn't important once this was done. Boris' change started using the completed plan stack for more than just the initial determination of the cooked stop reason, so you do need to preserve it as well. I don't think that letting the completed plans live a little longer should pose any problems. The plans should do whatever cleanup they are going to do when they get popped, and should not rely on the destructors to do this work. But it would be worth a quick audit to make sure I didn't get sloppy about that before we make this change, and we should document that requirement in the ThreadPlan dissertation at the beginning of ThreadPlan.h. Can you do that, and then we should be fine to go in? Repository: rL LLVM https://reviews.llvm.org/D28945 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
