From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-65557-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 19879 invoked by alias); 22 Jul 2009 10:46:26 -0000
Received: (qmail 19867 invoked by uid 22791); 22 Jul 2009 10:46:25 -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 10:46:13 +0000
Received: (qmail 18740 invoked from network); 22 Jul 2009 10:46:11 -0000
Received: from unknown (HELO orlando.local) (pedro@127.0.0.2)   by mail.codesourcery.com with ESMTPA; 22 Jul 2009 10:46:11 -0000
From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Subject: Re: [patch] Speed up find_pc_section
Date: Wed, 22 Jul 2009 15:23:00 -0000
User-Agent: KMail/1.9.10
Cc: Paul Pluzhnikov <ppluzhnikov@google.com>,  Tom Tromey <tromey@redhat.com>
References: <8ac60eac0907161724v40e5bd8bg7877d8901b8d7b6e@mail.gmail.com> <m3iqhmf2b3.fsf@fleche.redhat.com> <8ac60eac0907211318j11706eb3u2339901a832e2360@mail.gmail.com>
In-Reply-To: <8ac60eac0907211318j11706eb3u2339901a832e2360@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;   charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-Id: <200907221146.05270.pedro@codesourcery.com>
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2009-07/txt/msg00536.txt.bz2

On Tuesday 21 July 2009 21:18:26, Paul Pluzhnikov wrote:

> +
> +/* Set objfiles_updated_p so section map will be rebuilt next time it
> + =A0 is used. =A0Called by executable_changed observer. =A0*/
> +
> +static void
> +set_objfiles_updated_on_exe_change (void)
> +{
> + =A0objfiles_updated_p =3D 1; =A0/* Rebuild section map next time we nee=
d it. =A0*/
> +}
> +
> +/* Set objfiles_updated_p so section map will be rebuilt next time it
> + =A0 is used. =A0Called by solib_loaded/unloaded observer. =A0*/
> +
> +static void
> +set_objfiles_updated_on_solib_activity (struct so_list *so_list)
> +{
> + =A0objfiles_updated_p =3D 1; =A0/* Rebuild section map next time we nee=
d it. =A0*/
> +}
> +
> +void
> +_initialize_objfiles (void)
> +{
> + =A0observer_attach_executable_changed (set_objfiles_updated_on_exe_chan=
ge);
> + =A0observer_attach_solib_loaded (set_objfiles_updated_on_solib_activity=
);
> + =A0observer_attach_solib_unloaded (set_objfiles_updated_on_solib_activi=
ty);
> +}

Are these observers sufficient?  There are other sources of
objfiles !exec && !solibs.  What about e.g., add-symbol-file?  E.g.:

$ gdb
(gdb) add-symbol-file fooprogram 0x1234 (-s ... ... ...)
(gdb) p foosymbol

I don't think the map will be built, thus the section by pc won't
be found.

I'm also looking at objfile_relocate (from remote targets using
qOffsets for example), and wondering where is the map reset?

--=20
Pedro Alves