From patchwork Thu Jan 29 07:03:04 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Evans X-Patchwork-Id: 4840 Received: (qmail 7657 invoked by alias); 29 Jan 2015 07:03:57 -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 7619 invoked by uid 89); 29 Jan 2015 07:03:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL, BAYES_00, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f49.google.com Received: from mail-pa0-f49.google.com (HELO mail-pa0-f49.google.com) (209.85.220.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 29 Jan 2015 07:03:53 +0000 Received: by mail-pa0-f49.google.com with SMTP id fa1so35458991pad.8 for ; Wed, 28 Jan 2015 23:03:51 -0800 (PST) X-Received: by 10.69.16.99 with SMTP id fv3mr3151083pbd.98.1422515031757; Wed, 28 Jan 2015 23:03:51 -0800 (PST) Received: from seba.sebabeach.org.gmail.com (173-13-178-53-sfba.hfc.comcastbusiness.net. [173.13.178.53]) by mx.google.com with ESMTPSA id v11sm6735444pdi.13.2015.01.28.23.03.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jan 2015 23:03:50 -0800 (PST) From: Doug Evans To: Pedro Alves Cc: gdb-patches@sourceware.org, brobecker@adacore.com Subject: Re: [PATCH][PR symtab/17855] Fix. References: <54C0E1FF.4050201@redhat.com> Date: Wed, 28 Jan 2015 23:03:04 -0800 In-Reply-To: <54C0E1FF.4050201@redhat.com> (Pedro Alves's message of "Thu, 22 Jan 2015 11:41:51 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 X-IsSubscribed: yes Pedro Alves writes: > On 01/20/2015 06:26 AM, Doug Evans wrote: >> Hi. >> >> This patch fixes symtab/17855. >> Basically the issue is that breakpoint_re_set is currently being called >> before observer_notify_new_objfile (NULL), and thus the ada symbol >> cache (and the general symbol cache of a separate patch) aren't being >> flushed first, so that when breakpoints are reset symbol lookup is being >> done on a stale cache. >> >> Regression tested on amd64-linux. >> >> 2015-01-19 Doug Evans >> >> PR symtab/17855 >> * symfile.c (clear_symtab_users): Notify observers of change before >> calling breakpoint_re_set. >> >> diff --git a/gdb/symfile.c b/gdb/symfile.c >> index d55e361..ad481de 100644 >> --- a/gdb/symfile.c >> +++ b/gdb/symfile.c >> @@ -3023,6 +3023,12 @@ clear_symtab_users (int add_flags) >> /* Someday, we should do better than this, by only blowing away >> the things that really need to be blown. */ >> >> + /* Notify anyone listening that the previous loaded symtab(s) are invalid. >> + It is important to do this before calling breakpoint_re_set as the latter >> + will try to look up symbols, and for example the symbol cache needs to >> + be flushed first. */ >> + observer_notify_new_objfile (NULL); >> + >> /* Clear the "current" symtab first, because it is no longer valid. >> breakpoint_re_set may try to access the current symtab. */ >> clear_current_source_symtab_and_line (); >> @@ -3032,7 +3038,6 @@ clear_symtab_users (int add_flags) >> breakpoint_re_set (); >> clear_last_displayed_sal (); >> clear_pc_function_cache (); >> - observer_notify_new_objfile (NULL); > > Looking at the whole function, ISTM that the breakpoint_re_set > call should move further down. I can imagine that breakpoint_re_set > could well hit a stale pc function cache, cleared only after by > clear_pc_function_cache. breakpoint.c:parse_breakpoint_sals also > references the last displayed sal. One would hope that breakpoint > re-set is independent of that, though the existing comment about > breakpoint_re_set accessing the current symtab leaves me > wondering. WDYT? > > Thanks, > Pedro Alves Like so? 2015-01-28 Doug Evans PR symtab/17855 * symfile.c (clear_symtab_users): Move call to breakpoint_re_set closer to end. diff --git a/gdb/symfile.c b/gdb/symfile.c index d55e361..bad244c 100644 --- a/gdb/symfile.c +++ b/gdb/symfile.c @@ -3023,13 +3023,8 @@ clear_symtab_users (int add_flags) /* Someday, we should do better than this, by only blowing away the things that really need to be blown. */ - /* Clear the "current" symtab first, because it is no longer valid. - breakpoint_re_set may try to access the current symtab. */ clear_current_source_symtab_and_line (); - clear_displays (); - if ((add_flags & SYMFILE_DEFER_BP_RESET) == 0) - breakpoint_re_set (); clear_last_displayed_sal (); clear_pc_function_cache (); observer_notify_new_objfile (NULL); @@ -3040,9 +3035,19 @@ clear_symtab_users (int add_flags) expression_context_block = NULL; innermost_block = NULL; + /* Now that most everything has been reset, reset any existing breakpoints. + Reasons for doing this after the above are that breakpoint resetting may + involve: + - reading the current source symtab and line, + - reading the last displayed sal, + - reading the pc function cache, + - symbol lookup which requires, for example, invalidating any caches + first. */ + if ((add_flags & SYMFILE_DEFER_BP_RESET) == 0) + breakpoint_re_set (); + /* Varobj may refer to old symbols, perform a cleanup. */ varobj_invalidate (); - } static void