From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21554 invoked by alias); 19 Nov 2001 19:38:41 -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 21415 invoked from network); 19 Nov 2001 19:38:36 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sourceware.cygnus.com with SMTP; 19 Nov 2001 19:38:36 -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 LAA21652; Mon, 19 Nov 2001 11:38:33 -0800 (PST) Received: (from kev@localhost) by cse.cygnus.com (8.9.3/8.9.3) id MAA16385; Mon, 19 Nov 2001 12:38:21 -0700 Date: Thu, 08 Nov 2001 10:49:00 -0000 From: Kevin Buettner Message-Id: <1011119193821.ZM16384@ocotillo.lan> In-Reply-To: Daniel Jacobowitz "Re: gdb and dlopen" (Nov 19, 2:16pm) 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> <20011119141617.A20878@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/msg00092.txt.bz2 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? Kevin