From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32195 invoked by alias); 20 Feb 2004 18:48:55 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 32178 invoked from network); 20 Feb 2004 18:48:54 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 20 Feb 2004 18:48:54 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AuFhf-0004Nb-31; Fri, 20 Feb 2004 13:48:47 -0500 Date: Fri, 20 Feb 2004 18:48:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Elena Zannoni , David Carlton , gdb@sources.redhat.com Subject: Re: Huge slowdown since 6.0 Message-ID: <20040220184847.GA16796@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Elena Zannoni , David Carlton , gdb@sources.redhat.com References: <20040218210927.GA16641@nevyn.them.org> <20040220050905.GA15209@nevyn.them.org> <16438.14300.323849.306261@localhost.redhat.com> <40363D78.9080708@gnu.org> <16438.18096.205403.553354@localhost.redhat.com> <40364CF2.5020704@gnu.org> <20040220182411.GA14238@nevyn.them.org> <403655D4.1020102@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <403655D4.1020102@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-02/txt/msg00293.txt.bz2 On Fri, Feb 20, 2004 at 01:45:40PM -0500, Andrew Cagney wrote: > >On Fri, Feb 20, 2004 at 01:07:46PM -0500, Andrew Cagney wrote: > > > >>>Even if we start out with on-demand, it should work better. Given: > >>> > >>> $ gdb foo > >>> (gdb) break main > >>> (gdb) run > >>> > >>>why is GDB loading glibc's symbols? > > > > > >Main might be a function defined in a shared library. Even if we found > >a definition in the executable, it might be a PLT loading slot. KDE > >on i386 will demonstrate this exact behavior. > > It's been suggested to me that we should create a hacked gdb that > records all commands et.al. to a file, and then offers to send them to > us. That way we know what is, rather than what might be. > > If we knew for instance that only 10% of users set breakpoints outside > of the main executible, then we'd also know that we were frustrating 90% > of users by making them sit around waiting for needless symbol table > reads :-( > > On the other hand, if we knew that the first thing people did was: > (gdb) break > we'd have an entirely different problem. My point is that whether or not "break main" shows up as resolving to the main executable, to get it right in the general case, we also need shared library symbols. I discussed this at length in the last thread about multiple-address breakpoints. For main in particular maybe it's a non-issue, but not for any other function. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer