This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 01/16 v2] Refactor native follow-fork
- From: Pedro Alves <palves at redhat dot com>
- To: Don Breazeal <donb at codesourcery dot com>, gdb-patches at sourceware dot org
- Date: Fri, 05 Sep 2014 15:20:15 +0100
- Subject: Re: [PATCH 01/16 v2] Refactor native follow-fork
- Authentication-results: sourceware.org; auth=none
- References: <1407434395-19089-1-git-send-email-donb at codesourcery dot com> <1408580964-27916-2-git-send-email-donb at codesourcery dot com>
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