2 problems with debugger

[Vladimir Prus]

On Monday 06 November 2006 01:02, Andreas Pakulat wrote:
> On 05.11.06 23:23:06, Vladimir Prus wrote:
> > On Sunday 05 November 2006 19:09, Andreas Pakulat wrote:
> > > 1. Startup of kdevelop inside kdevelop is really slow here and it seems
> > > it got sth. to do with how many breakpoints I have set and enabled. I
> > > tend to set breakpoints when I debug sth but never unset them, unless
> > > in a later debug session I stumble upon them. So I had like 20
> > > breakpoints in the qmake manager set and it seems that kdevelop
> > > debugger takes ages to set them all.
> > >
> > > I also noted that a self-compiled gdb 6.5 is a bit faster than the
> > > debian packaged gdb 6.4.90 (which the maintainer claims to be nearly
> > > the same as 6.5)
> > >
> > > I can't attach a konsole output, too big. I put it on
> > >
> > > www.apaku.de/vardata/debugger.out
> > >
> > > It contains the logs from 2 debug session, the first starts kdevelop
> > > with no breakpoints and then I set a couple of breakpoints and start it
> > > again.  The 2nd case needed approx 12 minutes to start, while the first
> > > was nearly instantanious.
> >
> > Looking at the log, the problem is obvious, while the solution is not
> > quite.
>
> Thats what I thought too :)
>
> > Most of KDevelop code is in libraries, which are loaded after startup.
> > When you start KDevelop gdb does not yet see those libraries, so it tries
> > to reinsert breakpoint after each plugin is loaded, which takes quite
> > some time.
>
> Yeah, is there a way to give gdb a list of breakpoints on the
> commandline and tell him to try to load them on each lib-load? I'd like
> to check wether "plain" gdb behaves the same...

Yes, create a file containing the following:

	break some_file:NN
	break some_other_file:MM

then start gdb as

	gdb -x <the file created above> application

and then type "run".

> > I'm not sure though how it comes to take 12 mins.
>
> Well, as I said its better with self-compiled gdb6.5, thus I also
> suspect the debian package to have a problem here (they have some extra
> patches and they compile with -O2 -g).

This is strange. Perphaps there are some optimisations that went into 6.5.

> > In fact, it looks that you've used the "restart" button as opposed to
> > stopping the debugger and staring it aflesh.
>
> I always press stop and then hit F9/start program, I may have forgotten
> to press stop that time but I certainly didn't hit the restart programm
> button.

OK.

>
> > Can you check if stopping/starting works
> > better? I might be that gdb does something wrong exactly in "restart"
> > scenario, in which case I might be able to fix something.
>
> Ok, freshly started kdevelop, took about 6 minutes with 34 breakpoints
> using debian-gdb, 2 minutes with self-compiled gdb. I guess I should
> write a bugreport to debian, seems like their gdb is slow at loading lib
> symbols (the most time is consumed loading all the plugins).

This is again weird. I'll talk to the Debian maintainer myself too, to find 
out what's the right way to pinpoint the problem.

If you reproduce this problem with console gdb, I think it's possible to do 
this:

	1. Re-configure gdb with "--enable-profiling"
	2. Before run, use "maint set profile"
	3. That will create output file that can be analyzed by
	gprof, or sent to me

> Also do you know wether the time for setting those breakpoints depends
> on the CPU speed that much? teatime tested a it without any breakpoints
> and needed 11 seconds till full kdev, I need about a minute (IIRC). And
> with 13 breakpoints it took him about a minute. He has a AMD2500, while
> I have a Pentium M 1.4GHz...

I'd suppose this more L2-cache size bound, since most probably gdb creates 
huge data structures. But only profile can tell for sure.

- Volodya