PATCH: Fork event updates, part the fourth

[Daniel Jacobowitz <drow at mvista dot com>]

Here we go again.  These patches represent a departure from my earlier
direction.  Basically, what I was doing was the same thing the HP people
did: implementing the feature for one target (two in my case) and then
trying to make it look as if it were portable.  Rather than playing mind
games ("would this work on HP/UX if I did the work to turn it on?"), I just
fixed HP/UX support.  It proved to be easier than I thought.  The reason it
wasn't working was Jeff Law's patch from some time ago to use
TT_LWP_CONTINUE instead of TT_PROC_CONTINUE.  Once I fixed that, it wasn't
hard to make everything else fall into place.

This patch removes the infrun hackery expecting two TARGET_WAITKIND_FORKED
events.  Instead it modifies the hppah-nat child_wait function to return
only the interesting fork event.  This uses TARGET_WAITKIND_IGNORE, which is
like TARGET_WAITKIND_SPURIOUS but does not trigger a resume.  A logical
followup patch will probably rename both SPURIOUS and IGNORE, since I kept
getting them confused while I was doing this.  I updated the comments on
TARGET_WAITKIND_IGNORE since it isn't only used for the evil remote-async
output packets now.

I also modify _IGNORE to call prepare_to_wait.  This has essentially no
effect; since the target isn't stopped, flushing the register cache doesn't
really do anything; ditto for the other things prepare_to_wait does.  But
it's much more consistent.

This'll go in on Monday or Tuesday unless anyone has comments, with the
other two I'm about to post.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2002-12-06  Daniel Jacobowitz  <drow@mvista.com>

	* hppah-nat.c (child_wait): Return TARGET_WAITKIND_IGNORE
	for the parent's fork event.
	* infrun.c (handle_inferior_event): Only expect one fork event.
	Call prepare_to_wait for TARGET_WAITKIND_IGNORE.  Update comment.
	* target.h: Update comment for TARGET_WAITKIND_IGNORE.

diff -Nurp gdb.clean/hppah-nat.c gdb.work1/hppah-nat.c
--- gdb.clean/hppah-nat.c	2002-11-16 14:24:41.000000000 -0500
+++ gdb.work1/hppah-nat.c	2002-12-05 14:36:53.000000000 -0500
@@ -524,13 +524,23 @@ child_wait (ptid_t ptid, struct target_w
 	  return pid_to_ptid (pid);
 	}
 
-      if (hpux_has_forked (pid, &related_pid)
-	  && ((pid == PIDGET (inferior_ptid)) 
-	      || (related_pid == PIDGET (inferior_ptid))))
+      if (hpux_has_forked (pid, &related_pid))
 	{
-	  ourstatus->kind = TARGET_WAITKIND_FORKED;
-	  ourstatus->value.related_pid = related_pid;
-	  return pid_to_ptid (pid);
+	  /* Ignore the parent's fork event.  */
+	  if (pid == PIDGET (inferior_ptid))
+	    {
+	      ourstatus->kind = TARGET_WAITKIND_IGNORE;
+	      return inferior_ptid;
+	    }
+
+	  /* If this is the child's fork event, report that the
+	     process has forked.  */
+	  if (related_pid == PIDGET (inferior_ptid))
+	    {
+	      ourstatus->kind = TARGET_WAITKIND_FORKED;
+	      ourstatus->value.related_pid = pid;
+	      return inferior_ptid;
+	    }
 	}
 
       if (hpux_has_vforked (pid, &related_pid)
diff -Nurp gdb.clean/infrun.c gdb.work1/infrun.c
--- gdb.clean/infrun.c	2002-12-03 22:02:10.000000000 -0500
+++ gdb.work1/infrun.c	2002-12-05 14:36:53.000000000 -0500
@@ -1478,24 +1478,9 @@ handle_inferior_event (struct execution_
       stop_signal = TARGET_SIGNAL_TRAP;
       pending_follow.kind = ecs->ws.kind;
 
-      /* Ignore fork events reported for the parent; we're only
-         interested in reacting to forks of the child.  Note that
-         we expect the child's fork event to be available if we
-         waited for it now. */
-      if (ptid_equal (inferior_ptid, ecs->ptid))
-	{
-	  pending_follow.fork_event.saw_parent_fork = 1;
-	  pending_follow.fork_event.parent_pid = PIDGET (ecs->ptid);
-	  pending_follow.fork_event.child_pid = ecs->ws.value.related_pid;
-	  prepare_to_wait (ecs);
-	  return;
-	}
-      else
-	{
-	  pending_follow.fork_event.saw_child_fork = 1;
-	  pending_follow.fork_event.child_pid = PIDGET (ecs->ptid);
-	  pending_follow.fork_event.parent_pid = ecs->ws.value.related_pid;
-	}
+      pending_follow.fork_event.saw_child_fork = 1;
+      pending_follow.fork_event.parent_pid = PIDGET (ecs->ptid);
+      pending_follow.fork_event.child_pid = ecs->ws.value.related_pid;
 
       stop_pc = read_pc_pid (ecs->ptid);
       ecs->saved_inferior_ptid = inferior_ptid;
@@ -1703,13 +1688,15 @@ handle_inferior_event (struct execution_
 
       /* We had an event in the inferior, but we are not interested
          in handling it at this level. The lower layers have already
-         done what needs to be done, if anything. This case can
-         occur only when the target is async or extended-async. One
-         of the circumstamces for this to happen is when the
-         inferior produces output for the console. The inferior has
-         not stopped, and we are ignoring the event. */
+         done what needs to be done, if anything.
+	 
+	 One of the possible circumstances for this is when the
+	 inferior produces output for the console. The inferior has
+	 not stopped, and we are ignoring the event.  Another possible
+	 circumstance is any event which the lower level knows will be
+	 reported multiple times without an intervening resume.  */
     case TARGET_WAITKIND_IGNORE:
-      ecs->wait_some_more = 1;
+      prepare_to_wait (ecs);
       return;
     }
 
diff -Nurp gdb.clean/target.h gdb.work1/target.h
--- gdb.clean/target.h	2002-11-16 14:24:41.000000000 -0500
+++ gdb.work1/target.h	2002-12-06 17:00:18.000000000 -0500
@@ -112,8 +112,8 @@ enum target_waitkind
        inferior.  */
     TARGET_WAITKIND_SPURIOUS,
 
-    /* This is used for target async and extended-async
-       only. Remote_async_wait() returns this when there is an event
+    /* An event has occured, but we should wait again.
+       Remote_async_wait() returns this when there is an event
        on the inferior, but the rest of the world is not interested in
        it. The inferior has not stopped, but has just sent some output
        to the console, for instance. In this case, we want to go back