[Lldb-commits] [PATCH] D129521: Add the ability to run expressions that call fork() or vfork().

[Greg Clayton via Phabricator via lldb-commits]

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