From patchwork Sat Feb 7 00:51:13 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Evans X-Patchwork-Id: 4952 Received: (qmail 18796 invoked by alias); 7 Feb 2015 00:51:19 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 18784 invoked by uid 89); 7 Feb 2015 00:51:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-qc0-f202.google.com Received: from mail-qc0-f202.google.com (HELO mail-qc0-f202.google.com) (209.85.216.202) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sat, 07 Feb 2015 00:51:17 +0000 Received: by mail-qc0-f202.google.com with SMTP id r5so1821228qcx.1 for ; Fri, 06 Feb 2015 16:51:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-type; bh=cl8LqT81jksV8XIgVi0Ms8cQqbbmgCZdOwuzUiUvajc=; b=DJikgJFWWrz4wSML6YZh3AKDXy8/4I6NU9a7ONZykjiJpTqp5EfVLyd08d4HvWON2n G5Ysz3E1lw0ED9Z6bgPX3SrH0RsAlOthCABm9XaHrjdnibqlrB/vkpe1V81tuV0h8J0e cmI4h4sIcppXGqlfk07YPtBnvCMgxRRohpYM7heDEpQyydxoFomlLNTvrXvR7NjHHiGG CPMJ4W6nAg5FhRVHhLlvGhqg33+wfkxs9NVMpHhCD/FeN1OtmZGhcpJ2JnVzL3Sa5nbC xZ5/uxL9BIwZpsj3VpOef0llRfaFwEc/6mFPBN5tsbEZrNCm7ku49wawbRJ96BkIIoq2 RDpQ== X-Gm-Message-State: ALoCoQkcZdl2gQqPs2nu/NxnocXraMCo6+cB90Edb3g59tU0/AXCQtDBFvN+pdM+xJQw7rRPW+Ailcm5AczJNIrkjQdpu/gKHfbtHUtVNpp4C3/G3t2WHrbGiR2NrbQEyTtrtwMdo/HX4Get/yFYv1eY3It8U2ey6LrWeQmSZIxtthWLcTCqyqU= X-Received: by 10.236.230.39 with SMTP id i37mr5461004yhq.47.1423270275000; Fri, 06 Feb 2015 16:51:15 -0800 (PST) Received: from corpmail-nozzle1-2.hot.corp.google.com ([100.108.1.103]) by gmr-mx.google.com with ESMTPS id fg3si745988qcb.1.2015.02.06.16.51.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Feb 2015 16:51:14 -0800 (PST) Received: from ruffy.mtv.corp.google.com ([172.17.128.44]) by corpmail-nozzle1-2.hot.corp.google.com with ESMTPS id zOhZG4jA.1; Fri, 06 Feb 2015 16:51:14 -0800 From: Doug Evans To: gdb-patches@sourceware.org Subject: [PATCH][PR python/17936] Only emit one clear_objfiles event for main + separate debug file Date: Fri, 06 Feb 2015 16:51:13 -0800 Message-ID: MIME-Version: 1.0 X-IsSubscribed: yes Hi. This patch fixes 17936 by moving the call to observer_notify_new_objfile (NULL) up to a point before any symbols are loaded. This call triggers a "clear_objfiles" python event. With current sources, when you load a binary with separate debug info the following events are emitted: 1) clear_objfiles 2) new_objfile (separate_debug_file_of_main) 3) clear_objfiles 4) new_objfile (main_objfile) This patch changes that to: 1) clear_objfiles 2) new_objfile (separate_debug_file_of_main) 3) new_objfile (main_objfile) which is much easier for some of my python scripts to work with. It also turns off SYMFILE_MAINLINE when loading separate debug files, which removes clear_symtab_users processing for the separate debug file of the main objfile. This call is unnecessary as it will be done later for the main objfile itself. It's odd that the new_objfile event for the separate debug file goes out first before the new_objfile event for the "real" objfile, but that's a separate PR 17937. There is still an issue of SYMFILE_DEFER_BP_RESET processing for separate debug files (there's no need to call breakpoint_re_set for them, unless they're added through the gdb.Objfile.add_separate_debug_file python function), but that's a separate issue, and not critical. Regression tested on amd64-linux. 2015-02-06 Doug Evans PR python/17936 * symfile.c (symbol_file_add_with_addrs): Call observer_notify_new_objfile (NULL) early, before loading symbols. (symbol_file_add_separate): Turn off SYMFILE_MAINLINE when loading separate debug files. (clear_symtab_users): Don't call observer_notify_new_objfile (NULL) here if SYMFILE_MAINLINE. diff --git a/gdb/symfile.c b/gdb/symfile.c index c2a71ec..3171c2c 100644 --- a/gdb/symfile.c +++ b/gdb/symfile.c @@ -1168,6 +1168,15 @@ symbol_file_add_with_addrs (bfd *abfd, const char *name, int add_flags, && !query (_("Load new symbol table from \"%s\"? "), name)) error (_("Not confirmed.")); + /* If mainline, send the new_objfile (NULL) notification now. + This is done here so that clients will see one event instead of one for + the main objfile and a second one for a possible separate debug file, and + will see the event before any objfiles are loaded including possible + separate debug files. Note that if there is a separate debug file, we + will end up back here from calling syms_from_objfile below. PR 17936. */ + if (mainline) + observer_notify_new_objfile (NULL); + objfile = allocate_objfile (abfd, name, flags | (mainline ? OBJF_MAINLINE : 0)); @@ -1260,7 +1269,7 @@ symbol_file_add_separate (bfd *bfd, const char *name, int symfile_flags, my_cleanup = make_cleanup_free_section_addr_info (sap); new_objfile = symbol_file_add_with_addrs - (bfd, name, symfile_flags, sap, + (bfd, name, symfile_flags & ~SYMFILE_MAINLINE, sap, objfile->flags & (OBJF_REORDERED | OBJF_SHARED | OBJF_READNOW | OBJF_USERLOADED), objfile); @@ -3030,7 +3039,11 @@ clear_symtab_users (int add_flags) clear_displays (); clear_last_displayed_sal (); clear_pc_function_cache (); - observer_notify_new_objfile (NULL); + + /* If this is the main objfile, the notification is sent out sooner, + by symbol_file_add_with_addrs. PR 17936. */ + if ((add_flags & SYMFILE_MAINLINE) == 0) + observer_notify_new_objfile (NULL); /* Clear globals which might have pointed into a removed objfile. FIXME: It's not clear which of these are supposed to persist