jimingham wrote: > We can move the code into Process::RunThreadPlan if that does indeed filter > up as you suggested. > > @jimingham since the DidFork and DidVFork calls need to be called with > internal data from the stop reason, what do you suggest we do? Do you want us > to add new virtual functions to StopInfo like: > > ``` > /// Ask a stop info if it should halt an expression. This could check any > settings > /// to see if the user wants us to stop during an expression or not. > virtual bool StopInfo::ShouldStopAnExpression(); > /// Handle any needed cleanup or functionality if this StopInfo is hit during > an > /// expressiona and StopInfo::ShouldStopAnExpression() returned false. > virtual void StopInfo::HandleStopDuringExpression(); > ``` > > Then the `StopInfoFork::PerformAction` and > `StopInfoFork::HandleStopDuringExpression` could both do the same thing and > call a internal function that does what is needed to get beyond the fork (and > same idea for vfork). We really don't want the code we add to cast a > `StopInfo *` to a `StopInfoFork *` so that we can extract the data needed to > call `void Process::DidFork(lldb::pid_t child_pid, lldb::tid_t child_tid)` or > `void Process::DidFork(lldb::pid_t child_pid, lldb::tid_t child_tid)` right?
I haven't followed the fork handling closely which is probably why I'm missing why this is a problem. The simplest case of "I want the fork to happen but I don't want to follow it" should just work, right? You are sitting in the RunThreadPlan WaitForEvent loop that's running the expression, and you pull a stop event off the queue, and discover that the thread's StopReason was eStopReasonFork. Since all you want is to let the forked process go off running, you continue. That's no different from the case where the you stopped for an eStopReasonFork in your main Process Listener loop and continued, right? The thread in the parent process will continue evaluating the expression and the forked child will get to run freely. Why doesn't that work? If you wanted to do something fancier, like "suppress forks in expressions" or "follow the fork in expressions" you would have to do some more work, but that would all be to make sure the parent process you are going to detach from is left in a copasetic state before doing that, and really Process::Detach should do that job. I must be missing something because I can't see why this doesn't just work. https://github.com/llvm/llvm-project/pull/184815 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
