From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 759 invoked by alias); 10 Mar 2002 19:23:30 -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 686 invoked from network); 10 Mar 2002 19:23:27 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 10 Mar 2002 19:23:27 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16k8uP-00010q-00; Sun, 10 Mar 2002 14:23:05 -0500 Date: Sun, 10 Mar 2002 11:23:00 -0000 From: Daniel Jacobowitz To: John Firebaugh Cc: gdb@sources.redhat.com Subject: Re: 5.1 extremely slow Message-ID: <20020310142305.A3635@nevyn.them.org> Mail-Followup-To: John Firebaugh , gdb@sources.redhat.com References: <200203101047.01780.jfirebaugh@kde.org> <200203101103.39102.jfirebaugh@kde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200203101103.39102.jfirebaugh@kde.org> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-03/txt/msg00088.txt.bz2 On Sun, Mar 10, 2002 at 11:03:39AM -0800, John Firebaugh wrote: > On Sunday 10 March 2002 10:47, John Firebaugh wrote: > > I've upgraded to 5.1.1 due to bugs in 4.x, but debugging almost any program > > is unbearably slow. I've attached some detailed debug output; here is a > > summary: > > Update: this is probably the same problem discussed in the thread "gdb and > dlopen": > > http://sources.redhat.com/ml/gdb/2001-10/msg00157.html > > Is there a fix for this yet? Not yet. It's a tricky problem, because we lose the ability to set breakpoints in early functions in shared libraries if we fix it. You aren't seeing that problem specifically as much as the hideous performance of the threads package. There's no way to disable thread debugging (should we add a set for that? I think we should!) but you can temporarily remove or make unreadable /lib/libthread_db.so.1 to disable it. It will automatically kick in if you are linked to -lpthread. We need to address some of the performance concerns of this code very badly. I have a few ideas but they will not be in time for 5.2. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer