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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
