From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23200 invoked by alias); 19 Nov 2001 21:36:40 -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 23126 invoked from network); 19 Nov 2001 21:36:33 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sourceware.cygnus.com with SMTP; 19 Nov 2001 21:36:33 -0000 Received: from drow by nevyn.them.org with local (Exim 3.32 #1 (Debian)) id 165w5Y-0006ey-00; Mon, 19 Nov 2001 16:36:24 -0500 Date: Thu, 08 Nov 2001 11:14:00 -0000 From: Daniel Jacobowitz To: Kevin Buettner Cc: Kimball Thurston , Andrew Cagney , gdb@sources.redhat.com Subject: Re: gdb and dlopen Message-ID: <20011119163624.A25053@nevyn.them.org> Mail-Followup-To: Kevin Buettner , Kimball Thurston , Andrew Cagney , gdb@sources.redhat.com References: <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> <20011119141617.A20878@nevyn.them.org> <1011119193821.ZM16384@ocotillo.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1011119193821.ZM16384@ocotillo.lan> User-Agent: Mutt/1.3.23i X-SW-Source: 2001-11/txt/msg00093.txt.bz2 On Mon, Nov 19, 2001 at 12:38:21PM -0700, Kevin Buettner wrote: > On Nov 19, 2:16pm, Daniel Jacobowitz 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. > > Are you sure caching will help? The cache has to be invalidated every > time GDB stops, right? > > If current_sos() is refetching some bit of memory more than once per > invocation, then perhaps this problem should be solved by some other > means? I'm absolutely sure. Or at least, I was... when I tested this, it was an obvious win. Now it is an obvious LOSS to turn on the cache. I'm not sure why, so I'll have to investigate it later. In 5.0.90-cvs it was a win and in current trunk it is a significant performance loss. This is in the context of a linuxthreads application. We do a ridiculous, staggering amount of memory transfer in order to debug a linuxthreads application, and parts of it are duplicated. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer