From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32295 invoked by alias); 18 Nov 2001 19:45:35 -0000 Mailing-List: contact gdb-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 32247 invoked from network); 18 Nov 2001 19:45:26 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sourceware.cygnus.com with SMTP; 18 Nov 2001 19:45:26 -0000 Received: from drow by nevyn.them.org with local (Exim 3.32 #1 (Debian)) id 165XsM-00013e-00; Sun, 18 Nov 2001 14:45:10 -0500 Date: Thu, 08 Nov 2001 00:22:00 -0000 From: Daniel Jacobowitz To: Kevin Buettner Cc: Kimball Thurston , Andrew Cagney , gdb@sources.redhat.com Subject: Re: gdb and dlopen Message-ID: <20011118144510.A19538@nevyn.them.org> Mail-Followup-To: Kevin Buettner , Kimball Thurston , Andrew Cagney , gdb@sources.redhat.com References: <20011016213252.A8694@nevyn.them.org> <20011016220353.A9538@nevyn.them.org> <3BCCF83F.8010401@cygnus.com> <20011017010849.A23345@nevyn.them.org> <3BCDA6CF.3000308@cygnus.com> <20011017141550.B10927@nevyn.them.org> <1011017195838.ZM5524@ocotillo.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1011017195838.ZM5524@ocotillo.lan> User-Agent: Mutt/1.3.23i X-SW-Source: 2001-11/txt/msg00082.txt.bz2 On Wed, Oct 17, 2001 at 12:58:38PM -0700, Kevin Buettner wrote: > On Oct 17, 12:09pm, Kimball Thurston wrote: > > > Along the same lines of just trying to clean up unnecessary work, I > > was seeing 2 scans of all the open dsos for each dlopen call - it > > looks like we are getting 2 BPSTAT_WHAT_CHECK_SHLIBS events (in > > infrun.c) for each dlopen which causes us to rescan everything. Is > > there a way to distinguish these two events, and only do the scan > > once? > > I haven't looked at how hard it'd be, but it seems to me that it'd > be a good idea for gdb to note that a shlib event has happened without > immediately doing anything about it. Then, when the target stops > for some other reason (than a shlib event), we handle all of them at > once. This should cut down on the memory traffic greatly. Actually implementing this, at first glance, is easy. However, there's a couple of interesting issues. For instance, suppose that we want to reset a breakpoint in a shared library; we need to read in the symbols for that shared library before we can do that. If we defer it, and there are no other breakpoints, then we'll never set the breakpoint and never stop. Thoughts? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer