From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7647 invoked by alias); 19 Nov 2001 19:16:28 -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 7578 invoked from network); 19 Nov 2001 19:16:23 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sourceware.cygnus.com with SMTP; 19 Nov 2001 19:16:23 -0000 Received: from drow by nevyn.them.org with local (Exim 3.32 #1 (Debian)) id 165ttx-0005T0-00; Mon, 19 Nov 2001 14:16:17 -0500 Date: Thu, 08 Nov 2001 09:44:00 -0000 From: Daniel Jacobowitz To: Kevin Buettner Cc: Kimball Thurston , Andrew Cagney , gdb@sources.redhat.com Subject: Re: gdb and dlopen Message-ID: <20011119141617.A20878@nevyn.them.org> Mail-Followup-To: Kevin Buettner , Kimball Thurston , Andrew Cagney , gdb@sources.redhat.com References: <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> <1011119170409.ZM16064@ocotillo.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1011119170409.ZM16064@ocotillo.lan> User-Agent: Mutt/1.3.23i X-SW-Source: 2001-11/txt/msg00091.txt.bz2 On Mon, Nov 19, 2001 at 10:04:09AM -0700, Kevin Buettner wrote: > 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. Yes. I don't know what we can really do about this - besides decreasing the total memory traffic for an update, which I think would be wise. Among other possibilities, do you have any comment on my suggestion for setting inferior memory to be cached by default if not otherwise specified? Currently we default to uncached, which is safer, but I can't think of many examples where it would be a problem to cache. > 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) I suppose this is a good idea. I'm not going to do it, as I'd much rather make as-early-as-possible (which is what I've wanted nine times out of ten when actually debugging something which used DSOs...) faster. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer