From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24687 invoked by alias); 17 May 2009 16:33:36 -0000 Received: (qmail 24659 invoked by uid 22791); 17 May 2009 16:33:28 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 17 May 2009 16:33:22 +0000 Received: (qmail 27928 invoked from network); 17 May 2009 16:33:20 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 17 May 2009 16:33:20 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: eliminate pending_follow.execd_pathname. Date: Sun, 17 May 2009 16:33:00 -0000 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905171733.40993.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-05/txt/msg00345.txt.bz2 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 * 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) {