From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12736 invoked by alias); 7 Nov 2002 18:42:54 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 12591 invoked from network); 7 Nov 2002 18:42:52 -0000 Received: from unknown (HELO brm-ex01.abacus-direct.com) (65.167.67.60) by sources.redhat.com with SMTP; 7 Nov 2002 18:42:52 -0000 Received: by brm-ex01.abacus-direct.com with Internet Mail Service (5.5.2655.55) id <47W1HZMF>; Thu, 7 Nov 2002 11:43:06 -0700 Message-ID: From: "Garriss, Michael" To: 'Mark Crosland' , gdb@sources.redhat.com Subject: RE: gcc 3.2, gdb 5.2.1, solaris2.8 sparc, slow Date: Thu, 07 Nov 2002 10:42:00 -0000 MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2002-11/txt/msg00069.txt.bz2 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 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, >