From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6476 invoked by alias); 22 Jul 2009 17:40:51 -0000 Received: (qmail 6457 invoked by uid 22791); 22 Jul 2009 17:40:49 -0000 X-SWARE-Spam-Status: No, hits=-2.3 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; Wed, 22 Jul 2009 17:40:42 +0000 Received: (qmail 3187 invoked from network); 22 Jul 2009 17:40:40 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 22 Jul 2009 17:40:40 -0000 From: Pedro Alves To: Paul Pluzhnikov Subject: Re: [patch] Speed up find_pc_section Date: Wed, 22 Jul 2009 18:10:00 -0000 User-Agent: KMail/1.9.10 Cc: tromey@redhat.com, gdb-patches@sourceware.org References: <8ac60eac0907161724v40e5bd8bg7877d8901b8d7b6e@mail.gmail.com> <200907221732.46472.pedro@codesourcery.com> <8ac60eac0907221016j410f890ald54ac66c7c3291f9@mail.gmail.com> In-Reply-To: <8ac60eac0907221016j410f890ald54ac66c7c3291f9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907221840.29588.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-07/txt/msg00555.txt.bz2 On Wednesday 22 July 2009 18:16:06, Paul Pluzhnikov wrote: > On Wed, Jul 22, 2009 at 9:32 AM, Pedro Alves wrote: > > > In the OBJF_USERLOADED case, you rebuild the map when you don't > > really need to. > > I think it's pretty clear that what I really need is a new 'remove_objfile' > kind of observer. Would setting objfiles_updated_p from e.g., unlink_objfile work? Both the map and unlink_objfile/free_objfile are private/implemented in objfiles.c; if nothing else outside needs the observer, we can avoid adding it. Otherwise, a new observer is fine. (the more transparent the cache is, the better the design looks, IMHO) > > You're also likely breaking xcoffsolib.c and the vmap code in exec.c, as > > it calls free_objfile without going through observers. > > This would be handled by the 'remove_objfile' observer, I think. I think so. > > > Given the new_objfile observer, do we still need the exec_changed and > > solib observers? > > No, I've removed that (new patch attached). I think that the need for the solib load/unload observer would go away too if the map is flushed on objfile removal/freeing/unlinking as well? Why would you need to know about solibs, if without the cache (that is, before the original patch) we'd just iterate over the objfiles' sections? That is, the lifetime of the cache should be at most the same as of the objfiles' sections, yes? Come to look at it deeper, what is happening with symbol_file_add_with_addrs_or_offsets, if the objfile has only minimal symbols (but still has sections)? allocate_objfile is called, which builds the section table, but, there's a path that does an early return before calling the new_objfile observer, if there are no symbols. > > Please look around and check that objfile->section_offsets or > > obj_section_offset isn't being used as an lvalue somewhere where > > the map cache isn't being flushed. > > I think new_objfile/remove_objfile will take care of any of these. Okay then. > Should I revert the find_pc_section patch, work up remove_objfile observer > patch, then re-apply find_pc_section patch once it's in better shape? It would be cleaner and easier to review, easier for you (I think), and better for the archives in the future, IMHO. But I don't mind much if a new patch is cooked on top. -- Pedro Alves