mib added a comment. In D118482#3279843 <https://reviews.llvm.org/D118482#3279843>, @jingham wrote:
> This seems wrong to me. Normal Processes don't get to choose which thread > the generic "which stop event is most important" logic selects, they just > report the stop events and then the higher level logic decides which one to > select. It seems more symmetric to have the ScriptedThreads work the same > way - after all they are free to assign whatever StopInfo they want to each > stop. Why do you need to force the result in the ScriptedProcess case? This is completely optional. The user doesn't really have to override the base method, in which case lldb won't force the ScriptedProcess to select a specific thread. It will use its current stopping logic to look at the ScriptedThreads stop reasons and determine which one it should select. However, in some cases (i.e. crashlogs), we only have very sparse metadata to construct the ScriptedThreads, so having the ability to select the most relevant thread to the user can be quite helpful. Also, I'm not sure a Scripted Process should share the exact same behavior as a Normal Process as they will eventually be able to report fully synthetic threads / frames, but I might be wrong on that. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D118482/new/ https://reviews.llvm.org/D118482 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
