This is the mail archive of the
mailing list for the GDB project.
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Date: Sun, 17 May 2009 17:33:40 +0100
- Subject: eliminate pending_follow.execd_pathname.
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.
2009-05-17 Pedro Alves <email@example.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(-)
--- 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
- char *execd_pathname;
@@ -1078,11 +1077,6 @@ a command like `return' or `jump' to con
pc = regcache_read_pc (regcache);
- case TARGET_WAITKIND_EXECD:
- /* follow_exec is called as soon as the exec event is seen. */
- pending_follow.kind = TARGET_WAITKIND_SPURIOUS;
@@ -2444,9 +2438,6 @@ handle_inferior_event (struct execution_
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
- 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. */