eliminate pending_follow.execd_pathname.

[Pedro Alves <pedro at codesourcery dot com>]

Storing exec events in pending_follow doesn't make sense, since
exec events are lever left pending to follow later --- when
infrun is notified of the TARGET_WAITKIND_EXECD event, the OS has
already given the inferior the new post-execl image,
hence the "follow_exec is called as soon as the exec event is seen."

In fact, nothing ever sets pending_follow.kind == TARGET_WAITKIND_EXECD
currently.  We can just get rid of pending_follow.execd_pathname.

I'm releasing ecs->ws.value.execd_pathname after we've done
following the exec --- nothing uses it from that point on,
and, it plugs a leak.

(I have no doubt that at some point we'll store a per-thread
last-waitstatus, and we'll want to hold as much last-event data
as possible to show in info-threads and to expose to python.
When we get there, we'll need to defer releasing execd_pathname
to thread resume or exit instead.)

Tested on x86-64-linux, and checked in.

-- 
Pedro Alves

2009-05-17  Pedro Alves  <pedro@codesourcery.com>

	* infrun.c (pending_follow): Remove execd_pathname member.
	(resume): No longer handle TARGET_WAITKIND_EXECD pending follow.
	(handle_inferior_event): When handling a TARGET_WAITKIND_EXECD
	event, don't copy `execd_pathname' to pending_follow, use the
	event copy instead.  Release `execd_pathname' once done with
	handling the event.

---
 gdb/infrun.c |   17 ++++++-----------
 1 file changed, 6 insertions(+), 11 deletions(-)

Index: src/gdb/infrun.c
===================================================================
--- src.orig/gdb/infrun.c	2009-05-17 16:49:40.000000000 +0100
+++ src/gdb/infrun.c	2009-05-17 17:06:40.000000000 +0100
@@ -268,7 +268,6 @@ static struct
     ptid_t child_pid;
   }
   fork_event;
-  char *execd_pathname;
 }
 pending_follow;
 
@@ -1078,11 +1077,6 @@ a command like `return' or `jump' to con
       pc = regcache_read_pc (regcache);
       break;
 
-    case TARGET_WAITKIND_EXECD:
-      /* follow_exec is called as soon as the exec event is seen. */
-      pending_follow.kind = TARGET_WAITKIND_SPURIOUS;
-      break;
-
     default:
       break;
     }
@@ -2444,9 +2438,6 @@ handle_inferior_event (struct execution_
     case TARGET_WAITKIND_EXECD:
       if (debug_infrun)
         fprintf_unfiltered (gdb_stdlog, "infrun: TARGET_WAITKIND_EXECD\n");
-      pending_follow.execd_pathname =
-	savestring (ecs->ws.value.execd_pathname,
-		    strlen (ecs->ws.value.execd_pathname));
 
       if (!ptid_equal (ecs->ptid, inferior_ptid))
 	{
@@ -2459,12 +2450,16 @@ handle_inferior_event (struct execution_
       /* This causes the eventpoints and symbol table to be reset.
          Must do this now, before trying to determine whether to
          stop.  */
-      follow_exec (inferior_ptid, pending_follow.execd_pathname);
-      xfree (pending_follow.execd_pathname);
+      follow_exec (inferior_ptid, ecs->ws.value.execd_pathname);
 
       ecs->event_thread->stop_bpstat = bpstat_stop_status (stop_pc, ecs->ptid);
       ecs->random_signal = !bpstat_explains_signal (ecs->event_thread->stop_bpstat);
 
+      /* Note that this is referenced from inside bpstat_stop_status
+	 above, through inferior_has_execd.  */
+      xfree (ecs->ws.value.execd_pathname);
+      ecs->ws.value.execd_pathname = NULL;
+
       /* If no catchpoint triggered for this, then keep going.  */
       if (ecs->random_signal)
 	{