jingham added a comment. Something else is going on then. The run to break point plan is just the subsidiary plan that implements the call function plan. The way the function call plan works is that finds some code which we know isn't going to get executed (_start or something like it), writes a stack frame that returns there, pushes the call frame for the function under that, pushes a run to _start thread plan and continues. Then when the function call is done, we hit the breakpoint we've set at _start. Before we report that event (and get back to the code in RunThreadPlan) the thread plan machinery should decide that the run to address plan is successfully completed, it will get popped, then the call function plan will resume control and notice it also is done. Since the call function plan is a "master plan" it will get popped but then the completion will get reported directly rather than continuing to unwind the plan stack. When you go to pick the plan to report for the stop it should be the top of the completed plan stack, the "thread plan to call function". Why in this particular case is the bottom of the completed stack getting handed out? That's what seems wrong.
Repository: rL LLVM https://reviews.llvm.org/D29144 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
