Re: [PATCH 01/16 v2] Refactor native follow-fork

Pedro Alves
2014-09-05T14:20:21Z

linux_child_follow_fork ends up with:

static int
linux_child_follow_fork (struct target_ops *ops, int follow_child,
int detach_fork)
{
int has_vforked;
int parent_pid, child_pid;

has_vforked = (inferior_thread ()->pending_follow.kind
== TARGET_WAITKIND_VFORKED);
parent_pid = ptid_get_lwp (inferior_ptid);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
if (parent_pid == 0)
parent_pid = ptid_get_pid (inferior_ptid);
child_pid
= ptid_get_pid (inferior_thread ()->pending_follow.value.related_pid);

if (!follow_child)
{
...
}
else
{
struct lwp_info *child_lp;

child_lp = add_lwp (inferior_ptid);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
child_lp->stopped = 1;
child_lp->last_resume_kind = resume_stop;

/* Let the thread_db layer learn about this new process. */
check_for_thread_db ();
}
}

Nothing appears to switch inferior_ptid to the child, so seems
like we're adding the child_lp with the wrong lwp (and calling
check_for_thread_db in the wrong context) ? Is this managing
to work by chance because follow_fork_inferior leaves inferior_ptid
pointing to the child? Then this at the top uses the wrong
inferior_thread ():

has_vforked = (inferior_thread ()->pending_follow.kind
== TARGET_WAITKIND_VFORKED);

and we're lucky that nothing end up using has_vforked in the
follow child path?

I'd much rather we don't have these assumptions in place.

These files / targets also have to_follow_fork implementations:

inf-ptrace.c: t->to_follow_fork = inf_ptrace_follow_fork;
inf-ttrace.c: t->to_follow_fork = inf_ttrace_follow_fork;

which will break if we don't adjust them as well. Did you
check whether the refactored code (follow_fork_inferior)
makes sense for those?

Thanks,
Pedro Alves