RFA: Collect unexplained stopped threads in lin-lwp

RFA: Collect unexplained stopped threads in lin-lwp

[Daniel Jacobowitz]

[Michael, you more or less approved this patch in December, but it's seen a
few changes - linux_record_stopped_pid isn't a dummy any more.]

This patch just accepts processes we aren't currently debugging which report
a SIGSTOP, and throws them onto a list.  Not very useful by itself, but my
next patch will both cause this to happen (by enabling fork events) and
empty the list when it receives fork events.  I'm only submitting it
separately, because it was the last meaningful piece I could break out.

Is this OK?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2003-06-18  Daniel Jacobowitz  <drow@mvista.com>

	* config/nm-linux.h (linux_record_stopped_pid): New prototype.
	* lin-lwp.c (child_wait): Call linux_record_stopped_pid.
	(lin_lwp_wait): Likewise.  Update comments.
	* linux-nat.c (struct simple_pid_list, add_to_pid_list)
	(pull_pid_from_list, linux_record_stopped_pid): New.

diff -x '*.gmo' -Nurp src/gdb/config/nm-linux.h src-one/gdb/config/nm-linux.h
--- src/gdb/config/nm-linux.h	2003-06-15 16:56:47.000000000 -0400
+++ src-one/gdb/config/nm-linux.h	2003-06-18 15:19:11.000000000 -0400
@@ -78,6 +78,8 @@ extern int linux_proc_xfer_memory (CORE_
 				   int write, struct mem_attrib *attrib,
 				   struct target_ops *target);
 
+extern void linux_record_stopped_pid (int pid);
+
 #define CHILD_INSERT_FORK_CATCHPOINT
 #define CHILD_INSERT_VFORK_CATCHPOINT
 #define CHILD_INSERT_EXEC_CATCHPOINT
diff -x '*.gmo' -Nurp src/gdb/lin-lwp.c src-one/gdb/lin-lwp.c
--- src/gdb/lin-lwp.c	2003-06-04 16:51:28.000000000 -0400
+++ src-one/gdb/lin-lwp.c	2003-06-18 15:11:32.000000000 -0400
@@ -1109,6 +1109,23 @@ child_wait (ptid_t ptid, struct target_w
 	  save_errno = EINTR;
 	}
 
+      /* Check for stop events reported by a process we didn't already
+	 know about - in this case, anything other than inferior_ptid.
+
+	 If we're expecting to receive stopped processes after fork,
+	 vfork, and clone events, then we'll just add the new one to
+	 our list and go back to waiting for the event to be reported
+	 - the stopped process might be returned from waitpid before
+	 or after the event is.  If we want to handle debugging of
+	 CLONE_PTRACE processes we need to do more here, i.e. switch
+	 to multi-threaded mode.  */
+      if (pid != -1 && WIFSTOPPED (status) && WSTOPSIG (status) == SIGSTOP
+	  && pid != GET_PID (inferior_ptid))
+	{
+	  pid = -1;
+	  save_errno = EINTR;
+	}
+
       clear_sigio_trap ();
       clear_sigint_trap ();
     }
@@ -1272,6 +1289,22 @@ retry:
 
 	  lp = find_lwp_pid (pid_to_ptid (lwpid));
 
+	  /* Check for stop events reported by a process we didn't
+	     already know about - anything not already in our LWP
+	     list.
+
+	     If we're expecting to receive stopped processes after
+	     fork, vfork, and clone events, then we'll just add the
+	     new one to our list and go back to waiting for the event
+	     to be reported - the stopped process might be returned
+	     from waitpid before or after the event is.  */
+	  if (WIFSTOPPED (status) && !lp)
+	    {
+	      linux_record_stopped_pid (lwpid);
+	      status = 0;
+	      continue;
+	    }
+
 	  /* Make sure we don't report an event for the exit of an LWP not in
 	     our list, i.e.  not part of the current process.  This can happen
 	     if we detach from a program we original forked and then it
@@ -1282,6 +1315,13 @@ retry:
 	      continue;
 	    }
 
+	  /* NOTE drow/2003-06-17: This code seems to be meant for debugging
+	     CLONE_PTRACE processes which do not use the thread library -
+	     otherwise we wouldn't find the new LWP this way.  That doesn't
+	     currently work, and the following code is currently unreachable
+	     due to the two blocks above.  If it's fixed some day, this code
+	     should be broken out into a function so that we can also pick up
+	     LWPs from the new interface.  */
 	  if (!lp)
 	    {
 	      lp = add_lwp (BUILD_LWP (lwpid, GET_PID (inferior_ptid)));
diff -x '*.gmo' -Nurp src/gdb/linux-nat.c src-one/gdb/linux-nat.c
--- src/gdb/linux-nat.c	2003-06-15 16:56:47.000000000 -0400
+++ src-one/gdb/linux-nat.c	2003-06-18 16:47:55.000000000 -0400
@@ -54,12 +54,53 @@
 #define __WALL          0x40000000 /* Wait for any child.  */
 #endif
 
+struct simple_pid_list
+{
+  int pid;
+  struct simple_pid_list *next;
+};
+struct simple_pid_list *stopped_pids;
+
 /* This variable is a tri-state flag: -1 for unknown, 0 if PTRACE_O_TRACEFORK
    can not be used, 1 if it can.  */
 
 static int linux_supports_tracefork_flag = -1;
 
 \f
+/* Trivial list manipulation functions to keep track of a list of
+   new stopped processes.  */
+static void
+add_to_pid_list (struct simple_pid_list **listp, int pid)
+{
+  struct simple_pid_list *new_pid = xmalloc (sizeof (struct simple_pid_list));
+  new_pid->pid = pid;
+  new_pid->next = *listp;
+  *listp = new_pid;
+}
+
+static int
+pull_pid_from_list (struct simple_pid_list **listp, int pid)
+{
+  struct simple_pid_list **p;
+
+  for (p = listp; *p != NULL; p = &(*p)->next)
+    if ((*p)->pid == pid)
+      {
+	struct simple_pid_list *next = (*p)->next;
+	xfree (*p);
+	*p = next;
+	return 1;
+      }
+  return 0;
+}
+
+void
+linux_record_stopped_pid (int pid)
+{
+  add_to_pid_list (&stopped_pids, pid);
+}
+
+\f
 /* A helper function for linux_test_for_tracefork, called after fork ().  */
 
 static void

Re: RFA: Collect unexplained stopped threads in lin-lwp

[Michael Snyder]

Daniel Jacobowitz wrote:
> [Michael, you more or less approved this patch in December, but it's seen a
> few changes - linux_record_stopped_pid isn't a dummy any more.]
> 
> This patch just accepts processes we aren't currently debugging which report
> a SIGSTOP, and throws them onto a list.  Not very useful by itself, but my
> next patch will both cause this to happen (by enabling fork events) and
> empty the list when it receives fork events.  I'm only submitting it
> separately, because it was the last meaningful piece I could break out.
> 
> Is this OK?
> 

I realize these are not the same as LWPs, but is there any reason
you can't throw them in the existing LWP list, and then pull them
out discriminately?  (if that's a word...)

Just a suggestion.  If there is a reason, then yes, approved.

Re: RFA: Collect unexplained stopped threads in lin-lwp

[Daniel Jacobowitz]

On Wed, Jun 18, 2003 at 04:27:50PM -0700, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> >[Michael, you more or less approved this patch in December, but it's seen a
> >few changes - linux_record_stopped_pid isn't a dummy any more.]
> >
> >This patch just accepts processes we aren't currently debugging which 
> >report
> >a SIGSTOP, and throws them onto a list.  Not very useful by itself, but my
> >next patch will both cause this to happen (by enabling fork events) and
> >empty the list when it receives fork events.  I'm only submitting it
> >separately, because it was the last meaningful piece I could break out.
> >
> >Is this OK?
> >
> 
> I realize these are not the same as LWPs, but is there any reason
> you can't throw them in the existing LWP list, and then pull them
> out discriminately?  (if that's a word...)
> 
> Just a suggestion.  If there is a reason, then yes, approved.

There is a reason.  If I do that, we do things like expect attempt to
resume them... but it's somewhat important that we not resume them
until we've found their parent.  Why is not yet apparent, but will be
once we've started tracing vforks.  We need to have both parent and
child stopped at the point of contact in order to make breakpoints work
right.

Ideally GDB would just temporarily debug both processes.  Some day,
it'll be able to do that.  But now, it can't.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer