clayborg added a comment.

In D129521#3653770 <https://reviews.llvm.org/D129521#3653770>, @jingham wrote:

> 



> If that seems right, then for now you want to just ensure that the vfork is 
> allowed to continue while lldb follows the parent.  In that case, this isn't 
> quite the right way to do it.  If all you do is to say that the function call 
> plan doesn't explain the stop, then everybody else above you on the 
> ThreadPlanStack gets a whack at the stop event.  Maybe one of them is waiting 
> for a vfork stop for some other reason so they would react to this stop, 
> which isn't, I think, what you wanted.  You actually want the expression to 
> claim responsibility for the vfork, but also force the process to continue.

Actually we do need all of the stuff above us to get a chance to handle this 
because it needs to respond and detach from the child process. See more below

> This situation is pretty much the same as for breakpoints when we're ignoring 
> breakpoint hits in expressions.  The way that works is that 
> DoPlanExplainsStop says it does explain the stop, but then it overrides the 
> real stop info's "should stop" to force it to auto-continue.  In the 
> breakpoint case this is in the `if (m_ignore_breakpoints)` branch around  
> line 315:
>
>   if (m_ignore_breakpoints) {
>     LLDB_LOGF(log,
>               "ThreadPlanCallFunction::PlanExplainsStop: we are ignoring "
>               "breakpoints, overriding breakpoint stop info ShouldStop, "
>               "returning true");
>     m_real_stop_info_sp->OverrideShouldStop(false);
>     return true;
>   }
>
> That way nobody else gets a look at the stop, which is I'm pretty sure what 
> you want here, but when we get to deciding what to do in the ShouldStop 
> negotiation, we'll continue because we forced the relevant StopInfo to do 
> that.

I tried doing this and it stops everything from working. Fork handling needs to 
detach from the child process. I tried doing what you suggested above, but then 
none of that fork machinery gets invoked correctly and things go really south 
quickly.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129521/new/

https://reviews.llvm.org/D129521

_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to