From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29450 invoked by alias); 19 Nov 2001 17:04:46 -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 29408 invoked from network); 19 Nov 2001 17:04:42 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sourceware.cygnus.com with SMTP; 19 Nov 2001 17:04:42 -0000 Received: from cse.cygnus.com (cse.cygnus.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id JAA01518; Mon, 19 Nov 2001 09:04:38 -0800 (PST) Received: (from kev@localhost) by cse.cygnus.com (8.9.3/8.9.3) id KAA16065; Mon, 19 Nov 2001 10:04:09 -0700 Date: Thu, 08 Nov 2001 08:17:00 -0000 From: Kevin Buettner Message-Id: <1011119170409.ZM16064@ocotillo.lan> In-Reply-To: Daniel Jacobowitz "Re: gdb and dlopen" (Nov 18, 2:45pm) 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> <20011118144510.A19538@nevyn.them.org> X-Mailer: Z-Mail (4.0.1 13Jan97 Caldera) To: Daniel Jacobowitz , Kevin Buettner Subject: Re: gdb and dlopen Cc: Kimball Thurston , Andrew Cagney , gdb@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2001-11/txt/msg00089.txt.bz2 On Nov 18, 2:45pm, Daniel Jacobowitz wrote: > 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? After I proposed the above idea, Peter Schauer emailed me privately and noted that my idea would "break setting breakpoints in global object constructor code in shared libraries." He goes on to say that the "reenable breakpoint logic after every shlib load currently takes care of this." So, it looks like you've also noticed one of the concerns that Peter had regarding my idea. The only thing that I can think of is to introduce a GDB setting which indicates which behavior you want. Maybe call it "solib-reenable-breakpoints-after-load" and have it default to "true". (Which is what it currently does.) Then, if you care more about speed, you can shut it off if desired. Thinking about it some more, maybe it would be better extend auto-solib-add so that it has three settings: disabled (off) when-stopped as-early-as-possible (on) The "disabled" setting would be the same as what you currently get when you do ``set auto-solib off''. For the sake of backwards compatibility, we'd also continue to accept "off" as a synonym for "disabled". The "when-stopped" setting is the new one which would cause new shared libs to be checked for (and loaded) only when GDB stops for a non-shlib event. The "as-early-as-possible" setting is the same as what you currently get when you do ``set auto-solib on''. Again for the the sake of backwards compatibility, we'd also continue to accept "on" as a synonym for "as-early-as-possible". (I'm not very good at thinking of names and won't be at all offended if someone suggests something better...) Kevin