This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]