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

[Pedro Alves]

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