This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
RE: gcc 3.2, gdb 5.2.1, solaris2.8 sparc, slow
- From: Elena Zannoni <ezannoni at redhat dot com>
- To: "Garriss, Michael" <Michael dot Garriss at abacus-direct dot com>
- Cc: "'Mark Crosland'" <mjc at attbi dot com>, gdb at sources dot redhat dot com
- Date: Thu, 7 Nov 2002 15:17:48 -0500
- Subject: RE: gcc 3.2, gdb 5.2.1, solaris2.8 sparc, slow
- References: <F04FEE9A401F794AAB71C9004A8E020E0288D4CD@brm-ex01.abacus-direct.com>
Garriss, Michael writes:
> I second that.
>
> -----Original Message-----
> From: Mark Crosland [mailto:mjc@attbi.com]
> Sent: Thursday, November 07, 2002 11:36 AM
> To: gdb@sources.redhat.com
> Subject: Re: gcc 3.2, gdb 5.2.1, solaris2.8 sparc, slow
>
>
>
> OK, I will assume that no response means gdb is not suitable for medium ->
> large multi-threaded c++ development on solaris.
>
> Thanks,
> Mark
Actually no. gdb should be able to debug such applications. Would
you have a chance to poke around gdb and see what it's doing that
takes so long?
It may be the same thing reported in this thread:
http://sources.redhat.com/ml/gdb/2001-10/msg00157.html
Maybe the thread maintainers have some additional comments.
Elena
>
> On Wed, 6 Nov 2002, Mark Crosland wrote:
>
> >
> > I noticed a recent thread regarding rather slow response from gdb. I am
> > experiencing the same thing on solaris 2.8, sparc platform. It is an
> > enterpirse class server, not the fastest thing sun makes, but not slow.
> >
> > I built gcc 3.2
> > ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld
> > --disable-nls --prefix=/homedir/markc/gcc --enable-languages=c,c++
> > --enable-shared --enable-threads
> >
> > and then built gdb 5.2.1
> > mkdir build
> > cd build
> > /full/path/to/configure
> > make
> >
> > using gnu make 3.77
> >
> > solaris 2.8 sparc
> >
> > gdb responds with the most simple programs, but anything that isn't dirt
> > simple seems to cause it to take forever to do basic commands.
> >
> > I do "gdb myProgram", it starts right up, get the gdb prompt.
> >
> > "info address main" never returns
> > "break main" never returns
> >
> > CPU is peaked by gdb process
> >
> > If I say "run", it eventualy runs
> >
> > the program that is being run in gdb runs fine outside the debugger, isn't
> > really all that large, runs on several platforms, etc... it does load some
> > relatively average sized shared libraries (both from the OS and using
> > dlopen()). The program is multi-threaded.
> >
> > It is a c++ and c program
> >
> > The modules that contain main are compiled with -g. nm from binutils shows
> > lots of symbols.
> >
> > trying to get away from Sun compiler, but a debugger is a critical
> > piece...
> >
> > ???
> >
> > Mark,
> >