From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10782 invoked by alias); 22 Jul 2009 16:33:20 -0000 Received: (qmail 10705 invoked by uid 22791); 22 Jul 2009 16:33:19 -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 16:33:09 +0000 Received: (qmail 26883 invoked from network); 22 Jul 2009 16:33:02 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 22 Jul 2009 16:33:02 -0000 From: Pedro Alves To: Paul Pluzhnikov Subject: Re: [patch] Speed up find_pc_section Date: Wed, 22 Jul 2009 17:02:00 -0000 User-Agent: KMail/1.9.10 Cc: tromey@redhat.com, gdb-patches@sourceware.org References: <8ac60eac0907161724v40e5bd8bg7877d8901b8d7b6e@mail.gmail.com> <8ac60eac0907220849w3add6806h96e3df1d3257ac54@mail.gmail.com> In-Reply-To: <8ac60eac0907220849w3add6806h96e3df1d3257ac54@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200907221732.46472.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/msg00540.txt.bz2 On Wednesday 22 July 2009 16:49:39, Paul Pluzhnikov wrote: > On Wed, Jul 22, 2009 at 7:25 AM, Tom Tromey wrote: >=20 > > Paul, could you please either fix this ASAP, or revert the change while > > coming up with a fix? =A0Thanks. >=20 > Here is the fix for both issues. > Tested on Linux/x86_64, no regressions. >=20 > I'll work up a test case for add-symbol-file in a separate patch. > Not sure if I can make a test case for objfile_relocate though. >=20 > Thanks, Thanks, this looks better, but, there are a few issues I'd like to point ou= t. solib.c: /* Notify any observer that the shared object has been unloaded before we remove it from GDB's tables. */ observer_notify_solib_unloaded (gdb); *gdb_link =3D gdb->next; /* Unless the user loaded it explicitly, free SO's objfile. */ if (gdb->objfile && ! (gdb->objfile->flags & OBJF_USERLOADED)) free_objfile (gdb->objfile); In the OBJF_USERLOADED case, you rebuild the map when you don't really need to. You're also likely breaking xcoffsolib.c and the vmap code in exec.c, as it calls free_objfile without going through observers. Given the new_objfile observer, do we still need the exec_changed and solib observers? It sounds strange to me that this objfiles.c private cache needs observers from *other* modules. 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. --=20 Pedro Alves