jingham added a comment. In D96276#2549406 <https://reviews.llvm.org/D96276#2549406>, @kastiglione wrote:
> In D96276#2549007 <https://reviews.llvm.org/D96276#2549007>, @jingham wrote: > >> It still seems to me like a trampoline which knew that to implement itself, >> all it had to do was a couple of stepi's - for instance if a dyld stub knew >> that the stub had been filled in and would jump straight to the target, it >> could run without letting the other threads go. That's actually something >> the dyld stubs could figure out, they just don't at present. So I'd rather >> not remove this control. > > Happy to restore the stop_others parameter, but for my understanding I have > two questions: > > 1. Is the behavior you envision something that applies to these specific > thread plan subclasses (ie not dyld stubs) > 2. Will callers decide to stop others from the outside, or is the decision to > stop others something that these subclasses would make internally? Good questions. I was reading this incorrectly. This is the enqueuing plan telling the StepThrough plan whether to stop others. That actually seems like a bad thing to do, since the enqueuer can't really know whether it is actually safe to stop others while running the enqueued plan. These should go. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D96276/new/ https://reviews.llvm.org/D96276 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits