headers
wim delvaux | 1 Nov 2002 02:32
Favicon

why is gdb 5.2 so slow

I have been working with gdb 4.xx for years.

because of the dynamic library breakpoint handing I moved to 5.2 only to find 
it VERY slow.  I wrote this mail because I just had to kill gdb because it 
consumed 100 % cpu for MINUTES without doing anything usefull.

I run debian (testing version with the latests versions) I have currently 
installed 5.2.cvs 2002081.

Kernel version 2.4.18

I must admin that I do not have the fastest workhorse imaginable (a PIII 800) 
but that used to be no problem.

I also sometimes use ddd 3.1 with gdb and again in the 4-version I had no 
problem, executing was crips, debugging (almost) fun.

Now it skips breakpoints, takes ages to skip to the next statement, sometimes 
does not even want to stop (because it refers to some missing thread or 
something).  Only killing is the solution.

PLEASE help me out here !!!!

W
Permalink | Reply | 11 comments |
headers
Daniel Jacobowitz | 1 Nov 2002 04:52

Re: why is gdb 5.2 so slow

On Fri, Nov 01, 2002 at 02:32:19AM +0100, wim delvaux wrote:
> I have been working with gdb 4.xx for years.
> 
> because of the dynamic library breakpoint handing I moved to 5.2 only to find 
> it VERY slow.  I wrote this mail because I just had to kill gdb because it 
> consumed 100 % cpu for MINUTES without doing anything usefull.
> 
> I run debian (testing version with the latests versions) I have currently 
> installed 5.2.cvs 2002081.
> 
> Kernel version 2.4.18
> 
> I must admin that I do not have the fastest workhorse imaginable (a PIII 800) 
> but that used to be no problem.
> 
> I also sometimes use ddd 3.1 with gdb and again in the 4-version I had no 
> problem, executing was crips, debugging (almost) fun.
> 
> Now it skips breakpoints, takes ages to skip to the next statement, sometimes 
> does not even want to stop (because it refers to some missing thread or 
> something).  Only killing is the solution.
> 
> PLEASE help me out here !!!!

We can't help you unless you give us more information, of course.

What are you doing?  If you're complaining about slowness, you're
probably working with multithreaded applications.  Yeah, it's slower,
but better.  Every once in a while I work on making it faster but I
haven't had much success yet.
(Continue reading)

Permalink | Reply | 10 comments |
headers
wim delvaux | 1 Nov 2002 14:31
Favicon

Re: why is gdb 5.2 so slow

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

	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)

	What should i be looking at to give you more info.

	Thanx for the reply
Permalink | Reply | 9 comments |
headers
Elena Zannoni | 1 Nov 2002 15:14
Picon
Favicon

Re: set processor command

Andrew Cagney writes:
 > > Hi folks,
 > > 
 > > I did a small comparison between gdb 5.0, 5.1 and gdb 5.2.1 (configured as
 > > --target=powerpc-unknown-elf, solaris hosted) regarding the 'set processor'
 > > command. The output is:
 > > 
 > > gdb 5.0:
 > > --------
 > > GDB knows about the following PowerPC and RS6000 variants:
 > >   ppc-uisa  PowerPC UISA - a PPC processor as viewed by user-level code
 > >   rs6000    IBM RS6000 ("POWER") architecture, user-level view
 > >   403       IBM PowerPC 403
 > >   403GC     IBM PowerPC 403GC
 > >   505       Motorola PowerPC 505
 > >   860       Motorola PowerPC 860 or 850
 > >   601       Motorola PowerPC 601
 > >   602       Motorola PowerPC 602
 > >   603       Motorola/IBM PowerPC 603 or 603e
 > >   604       Motorola PowerPC 604 or 604e
 > >   750       Motorola/IBM PowerPC 750 or 740
 > > 
 > > gdb 5.1:
 > > --------
 > > Requires an argument. Valid arguments are rs6000:6000, rs6000:rs1, rs6000:rsc, rs6000:rs2,
powerpc:common, powerpc:603, powerpc:EC603e, powerpc:604, powerpc:403, powerpc:601,
powerpc:620, powerpc:630, powerpc:a35, powerpc:rs64ii, powerpc:rs64iii, powerpc:7400,
powerpc:MPC8XX, auto.
 > > 
 > > gdb 5.2.1:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Cagney | 1 Nov 2002 15:58
Picon
Favicon

Re: why is gdb 5.2 so slow

>>
>> 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'
(Continue reading)

Permalink | Reply | 8 comments |
headers
wim delvaux | 1 Nov 2002 16:15
Favicon

Re: why is gdb 5.2 so slow


> Can you file a bug?  http://sources.redhat.com/gdb/bugs/  Yes, that
> would quickly become frustrating.

	Done ... example attached

>
> A workaround is to add `set height 0' to your .gdbinit file.

	Will try that, thanx.  Indeed the number of prompts is related to
	the window size.

>
> I think you won the lottery in finding GDB's current known worst case :-)

	If I look at your explanation i think indeed I have the EXTREME situation
	here. I can easily have about 10 threads and about 60 dynamically loaded
	libraries and as said my PC is NOT the most powerfull ;-(

	Thanx again for the reply
Permalink | Reply | 2 comments |
headers
Daniel Jacobowitz | 1 Nov 2002 16:16

Re: why is gdb 5.2 so slow

On Fri, Nov 01, 2002 at 09:58:03AM -0500, Andrew Cagney wrote:
> 
> 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
(Continue reading)

Permalink | Reply | 4 comments |
headers
Daniel Jacobowitz | 1 Nov 2002 16:17

Re: why is gdb 5.2 so slow

On Fri, Nov 01, 2002 at 04:15:17PM +0100, wim delvaux wrote:
> 
> > Can you file a bug?  http://sources.redhat.com/gdb/bugs/  Yes, that
> > would quickly become frustrating.
> 
> 	Done ... example attached
> 
> >
> > A workaround is to add `set height 0' to your .gdbinit file.
> 
> 	Will try that, thanx.  Indeed the number of prompts is related to
> 	the window size.
> 
> >
> > I think you won the lottery in finding GDB's current known worst case :-)
> 
> 	If I look at your explanation i think indeed I have the EXTREME situation
> 	here. I can easily have about 10 threads and about 60 dynamically loaded
> 	libraries and as said my PC is NOT the most powerfull ;-(
> 
> 	Thanx again for the reply

Knew I forgot to suggest something.

If you don't need watchpoint support, please try running your program
under gdbserver instead of directly in GDB.  It should be buckets
faster.

--

-- 
Daniel Jacobowitz
(Continue reading)

Permalink | Reply | 1 comment |
headers
wim delvaux | 1 Nov 2002 17:13
Favicon

Re: why is gdb 5.2 so slow

>
> If you don't need watchpoint support, please try running your program
> under gdbserver instead of directly in GDB.  It should be buckets
> faster.

	Thanx, I will try that and report effect
Permalink | Reply | 0 comments |
headers
Nick Kelsey | 1 Nov 2002 17:36

Re: why is gdb 5.2 so slow

> Both.  Things we do wrong:
> - GDB can't handle being told that just one thread is stopped.  If we
> could, then we wouldn't have to stop all threads for shared library
> events; there's a mutex in the system library so we don't even have to
> worry about someone hitting the breakpoint.  We could also use this to
> save time on conditional breakpoints; if we aren't stopping, why stop
> all other threads?
> --
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer

We have exactly this problem at the moment - our system supports setting
breakpoints that only stop specified threads, however GDB cannot use this
support at the moment. If you have an interest for this support then I would
be interested in your thoughts.

Nick

Nick Kelsey
Senior Software Engineer
Ubicom
Permalink | Reply | 0 comments |

Gmane