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

Reply via email to