From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5066 invoked by alias); 1 Nov 2002 14:58:15 -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 4777 invoked from network); 1 Nov 2002 14:58:12 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 1 Nov 2002 14:58:12 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id DBDE13CB1; Fri, 1 Nov 2002 09:58:03 -0500 (EST) Message-ID: <3DC2967B.8050603@redhat.com> Date: Fri, 01 Nov 2002 06:58:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: wim delvaux , Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: why is gdb 5.2 so slow References: <20021101013219.QDL1261.amsfep12-int.chello.nl@there> <20021101035218.GA14509@nevyn.them.org> <20021101133135.LDS1274.amsfep14-int.chello.nl@there> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-11/txt/msg00002.txt.bz2 >> >> We can't help you unless you give us more information, of course. > > > Yes indeed, threads, lots of threads ! > > The applications are not large but have a lot of dynamically loaded > libraries, which, btw, has another annoying effect that when you > start gdb on a core file you have to press ENTER (q does not seem to work) > a few times because of the 'loading symbol messages'. Can you get rid of > that prompt ? Can you file a bug? http://sources.redhat.com/gdb/bugs/ Yes, that would quickly become frustrating. A workaround is to add `set height 0' to your .gdbinit file. > To give an example if you step over a function with 'n' it sometimes takes 5 > seconds to skip over that function (even if that function is nog complex at > all) I think you won the lottery in finding GDB's current known worst case :-) Daniel, humor me here ... GDB, to implement a thread-hop (step a single thread over a breakpoint) with something like (with a Linux Kernel): - gdb is notifed of a thread stopped on a breakpoint (wait), call this the `current thread' - gdb obtains that threads registers more ptrace - gdb stops (signal/wait) all the other threads forall threads signal/wait - gdb pulls all the breakpoints forall breakpoins ptrace - gdb single-steps the `current thread' ptrace/wait - gdb plants all the breakpoints forall breakpoints ptrace/ptrace - gdb resumes all threads forall threads ptrace A single-step is similar. I suspect that GDB debugging a multi-threaded shared library uses lots of thread-hops and lots of single steps :-(. GDB is either doing this very inefficiently (a lot more than the above) or there are some straightforward performance tweaks (step out of range?). It could also turn out, though, that the above is as good as it gets :-( I'd suspect a combination of both. This is because I recently noticed that on another OS (Hi JasonT) I noticed that it was a separate ptrace() to fetch each PPC register, even though ptrace() returns all 32 PPC registers in a single hit :-(. Anyway, my things-to-do-today is ktrace/oprofile GDB and see just how badly GDB is hitting the kernel. I've been told verbally it's pretty bad. On a bright note, I've also been told that a future Linux Kernel is going to support a stop all threads primative so that at least some of the above stupidity can be eliminated. Andrew