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

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

First off, I think making "follows-fork=child" work in expressions will be pretty tricky at present, since lldb can only control either the parent or the child.  But you have to make sure the parent side of the expression completes, so you can't let go of the parent right away.  You'll have to let the parent run a bit more before you can switch over to the child.  You either need to suspend the child while doing that (which may cause the parent side of the forked expression not to complete) or deal with the fact that the child might not survive the expression, and you're left with nothing to switch over to.  That seems messy.

If we get to the point where instead of replacing the parent with the child we create another Target/Process for the child, then dealing with the fork would be pretty straightforward.  You would temporarily force "follows-fork=both".  The function call plan would not explain the fork stop, the event would proceed to whoever does the fork following, it would create an new Target/Process for the child, and then letting both run will complete the expression with a live child to cooperate in that process.  Then if the follows-fork mode was actually "child" you would just discard the first Target/Process, and switch to the new one.

So I'd defer the feature of "follows-fork=child in expressions" till we are doing it that way, and for now just document that follows-fork does NOT pertain to forks created by running expressions.

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.

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.



================
Comment at: lldb/source/Target/ThreadPlanCallFunction.cpp:272
+      stop_reason == eStopReasonVForkDone) {
+    LLDB_LOGF(log, "ThreadPlanCallFunction::PlanExplainsStop not done for fork stop reasons.");
+    return false;
----------------
This is a bit silly, but "not done" sounds more to me like you didn't do PlanExplainsStop - which isn't true and would be weird - than that it is returning false.  Maybe just "returning false for fork stop reasons" would be better.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129521