jingham added a comment. In D66241#1631426 <https://reviews.llvm.org/D66241#1631426>, @clayborg wrote:
> Better. Might be good to put a comment inside CalculatePublicStopInfo() > regarding why the "SetStopInfo(GetStopInfo());" is needed. Seems like you > could just remove the code from the sight of it. I will leave that up to you > though. The thing you have to understand for this to make sense is that what you get from GetStopInfo depends on when you ask the question. If you have just stopped, but haven't gone through the ShouldStop mechanism, then there are no completed plans, and you get the raw stop info. But if you ask again after we've done "ShouldStop", then we're in a position to attribute the stop to the plan that was managing it. That's why I said explicitly you had to do CalculatePublicStopInfo after ShouldStop. I can refine the comment a bit to make this clearer. I think this is going to be a little opaque so long as we aren't making a real distinction between the private (what I used to call the actual stop info - there's even a few comments that still reference this...) and the public stop info. There's the added complication that sometimes you need to rewind to an old stop reason. For instance, you finish a step out, then run a function. Now the actual stop info is the breakpoint stop at the entry point that caught the end of the expression evaluation. The public stop info is "Completed Function Thread Plan". But showing that would be confusing, users don't care that a function was run, particularly if it was one they didn't directly cause. The stop info you actually want to show users is still "Completed step out plan". These complexities are overlaid on one stop info, and a bunch of stop_id variables. We also rely on the assumption that you can always re-fetch the private stop info with the plugin-implemented CalculateStopInfo call. But you have to be careful, because though you can rewind to an old Public StopInfo, you can't get back to the actual StopInfo that caused it - since the process has moved on. This requires other bits of fancy footwork. This all needs to be teased apart and better represented. But that's a task for another day. Repository: rLLDB LLDB CHANGES SINCE LAST ACTION https://reviews.llvm.org/D66241/new/ https://reviews.llvm.org/D66241 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
