Add the ability to run expressions that call fork() or vfork().

[clayborg]

Summary

Before this fix if you tried to call fork for vfork, the expression would stop when it received the eStopReasonFork or eStopReasonVFork in the thread plan that runs the expression. This is now fixed and I have added a test case.

[yinghuitan]

Change looks good to me. I will let @jingham take a second look before accepting.

I do wonder if there will be more unexpected signals (like SIGCHILD, SIGPIPE etc...) causing expression evaluation to pause? Should we maybe default to not stop on signals?

lldb/source/Target/ThreadPlanCallFunction.cpp

380

Undo this accidental change?

[labath]

The general idea makes sense, as we don't stop for forks even during normal execution. I'll too defer to @jingham on the implementation.

I am also wondering what is the current and expected behavior in the follow-fork=child mode. The user probably did not intend to follow the expression into the child process (and the thread plan will definitely get completely confused), but I'm also not sure that overriding the user setting is the right thing to do.

In D129521#3644244, @yinghuitan wrote:

I do wonder if there will be more unexpected signals (like SIGCHILD, SIGPIPE etc...) causing expression evaluation to pause? Should we maybe default to not stop on signals?

I think that's a different (and more complicated) discussion, and probably not relevant here. The default disposition of SIGCHLD is already set to no-stop, and if the user deliberately changed it, I wouldn't want to override it.

lldb/test/API/commands/expression/fork/TestForkExprs.py

17–19

unused code.

21

Technically, I think this should pass on all systems that have the fork function (i.e. they are not windows), even if we don't support fork tracking there.

[jingham]

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.

lldb/source/Target/ThreadPlanCallFunction.cpp

272

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.

[clayborg]

In 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.

[clayborg]

Ping. I would love to get this in if possible.

lldb/source/Target/ThreadPlanCallFunction.cpp

else
     stop_reason = m_real_stop_info_sp->GetStopReason();
   LLDB_LOG(log,
            "ThreadPlanCallFunction::PlanExplainsStop: Got stop reason - {0}.",
            Thread::StopReasonAsString(stop_reason));
 
   if (stop_reason == eStopReasonBreakpoint && BreakpointsExplainStop())
     return true;
 
+  if (stop_reason == eStopReasonFork || stop_reason == eStopReasonVFork ||
+      stop_reason == eStopReasonVForkDone) {
+    LLDB_LOGF(log, "ThreadPlanCallFunction::PlanExplainsStop not done for fork stop reasons.");
+    return false;
+  }
+
   // One more quirk here.  If this event was from Halt interrupting the target,
   // then we should not consider ourselves complete.  Return true to
   // acknowledge the stop.
   if (Process::ProcessEventData::GetInterruptedFromEvent(event_ptr)) {
     LLDB_LOGF(log, "ThreadPlanCallFunction::PlanExplainsStop: The event is an "
                    "Interrupt, returning true.");
     return true;
   }
void ThreadPlanCallFunction::DidPush() {
   // Now set the thread state to "no reason" so we don't run with whatever
   // signal was outstanding... Wait till the plan is pushed so we aren't
   // changing the stop info till we're about to run.
 
   GetThread().SetStopInfoToNothing();
 
 #ifndef SINGLE_STEP_EXPRESSIONS
   Thread &thread = GetThread();
-  m_subplan_sp = std::make_shared<ThreadPlanRunToAddress>(thread, m_start_addr, 
+  m_subplan_sp = std::make_shared<ThreadPlanRunToAddress>(thread, m_start_addr,
                                                           m_stop_other_threads);
 
   thread.QueueThreadPlan(m_subplan_sp, false);
   m_subplan_sp->SetPrivate(true);
 #endif
 }
 
 bool ThreadPlanCallFunction::WillStop() { return true; }

lldb/test/API/commands/expression/fork/Makefile

+CXX_SOURCES := main.cpp
+
+include Makefile.rules

lldb/test/API/commands/expression/fork/TestForkExprs.py

+"""
+Test some more expression commands.
+"""
+
+
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class ExprCommandsForkExpressions(TestBase):
+
+    NO_DEBUG_INFO_TESTCASE = True
+
+    def setUp(self):
+        # Call super's setUp().
+        TestBase.setUp(self)
+
+    @skipUnlessPlatform(["linux"])
+    def test_more_expr_commands(self):
+        """Test some more expression commands."""
+        self.build()
+
+        (target, process, self.thread, bkpt) = lldbutil.run_to_source_breakpoint(self,
+                                        'Stop here to evaluate expressions',
+                                         lldb.SBFileSpec("main.cpp"))
+
+        self.assertTrue(bkpt.IsValid())
+        bkpt.SetEnabled(False)
+        options = lldb.SBExpressionOptions()
+        options.SetIgnoreBreakpoints(True)
+        frame = self.thread.GetFrameAtIndex(0)
+
+        value = frame.EvaluateExpression("do_fork(argv, envp)", options)
+        self.assertTrue(value.IsValid())
+        self.assertSuccess(value.GetError())
+        value = frame.EvaluateExpression("do_vfork(argv, envp)", options)
+        self.assertTrue(value.IsValid())
+        self.assertSuccess(value.GetError())

lldb/test/API/commands/expression/fork/main.cpp

+#include <sys/types.h>
+#include <unistd.h>
+
+pid_t do_fork(char *const argv[], char *const envp[]) {
+  pid_t pid = fork();
+  if (pid == 0)
+    execve(argv[0], argv, envp);
+  return pid;
+}
+
+pid_t do_vfork(char *const argv[], char *const envp[]) {
+  pid_t pid = vfork();
+  if (pid == 0)
+    execve(argv[0], argv, envp);
+  return pid;
+}
+
+int main(int argc, char *const argv[], char *const envp[]) {
+  // Stop here to evaluate expressions
+  // Optionally call do_fork() when argc is 4 to make sure do_fork() doesn't get
+  // dead stripped
+  if (argc == 4)
+    do_fork(argv, envp);
+  // Optionally call do_vfork() when argc is 5 to make sure do_fork() doesn't
+  // get dead stripped
+  if (argc == 5)
+    do_vfork(argv, envp);
+  return 0;
+}