This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Terminally slow (75 seconds) on some steps
On Mon, 21 Jul 2003 10:21:08 -0400 Andrew Cagney <ac131313@redhat.com> wrote:
> So 11 seconds after you typed `run'.
> (The word startup can either be appled to that time after "run", or the
> time for gdb to reach the first "(gdb)" prompt :-().
Sorry, 11 seconds after "run" command. Gdb startup takes about one
second.
> Lots of shared libraries?
Mostly wxWindows, but there are other libraries:
libwx_gtkd-2.4.so.0 => /usr/lib/libwx_gtkd-2.4.so.0 (0x40019000)
libresolv.so.2 => /lib/libresolv.so.2 (0x4053a000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4054a000)
libdl.so.2 => /lib/libdl.so.2 (0x40577000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4057a000)
libm.so.6 => /lib/libm.so.6 (0x40626000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40647000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4064f000)
libc.so.6 => /lib/libc.so.6 (0x4069e000)
libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x407ae000)
libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x408d3000)
libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x40907000)
libgthread-1.2.so.0 => /usr/lib/libgthread-1.2.so.0 (0x4090a000)
libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x4090e000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x40931000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40939000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40946000)
libpng.so.2 => /usr/lib/libpng.so.2 (0x40a20000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40a4b000)
libtiff.so.3 => /usr/lib/libtiff.so.3 (0x40a6b000)
libz.so.1 => /usr/lib/libz.so.1 (0x40aad000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> Is it reproducable?
Yes. If you want to try it, get Mahogany from anonymous Cvs.
cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/mahogany login
cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/mahogany checkout M
mkdir build; cd build
./M/configure --enable-debug --with-experimental --with-wxdebug
--with-dmalloc
make && make install
src/M &
As I remember.
> >> What exactly is the system your using? Can you capture
> >> strace/ktrace/truss output for GDB doing a stepi?
> >
> >
> > I have no clue what are above three tools, but stepi is interactive. At
> > least I didn't bother to find the point where those 2 seconds are
> spent.
>
> Which operating system? That determines the tool you'll be using.
Sorry, Linux with 2.4 kernel.
> "step" is implemented using multiple "stepi". A slowdown can either be
> two many "stepi"s or a slow "stepi" implementation.
Gdb isn't doing any step/stepi in above tests. It's just big run without
breakpoints. Of course, I am doing steps when debugging, but with new
gdb, I haven't yet stumbled into single place where it is
non-interactive. I would have to do binary search over startup code, but
experience with old gdb tells that the cost is distributed.
> >> By `locks' you mean?
> >
> >
> > System native mutexes, I guess.
>
> Which operating system?
Linux. wxWindows hides this carefully, but libpthread seems to be used.