Re: why is gdb 5.2 so slow

[Andrew Cagney <ac131313 at redhat dot com>]

> > 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