From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30152 invoked by alias); 7 Nov 2002 21:54:01 -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 30141 invoked from network); 7 Nov 2002 21:53:59 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 7 Nov 2002 21:53:59 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id gA7LVGw25428 for ; Thu, 7 Nov 2002 16:31:16 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gA7Lrwf07651 for ; Thu, 7 Nov 2002 16:53:58 -0500 Received: from localhost.redhat.com (romulus-int.sfbay.redhat.com [172.16.27.46]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gA7Lrv515040; Thu, 7 Nov 2002 16:53:57 -0500 Received: by localhost.redhat.com (Postfix, from userid 469) id 06410FF79; Thu, 7 Nov 2002 16:49:50 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15818.57341.855172.175143@localhost.redhat.com> Date: Thu, 07 Nov 2002 13:54:00 -0000 To: Mark Crosland Cc: Elena Zannoni , gdb@sources.redhat.com Subject: RE: gcc 3.2, gdb 5.2.1, solaris2.8 sparc, slow In-Reply-To: References: <15818.51820.811781.873857@localhost.redhat.com> X-SW-Source: 2002-11/txt/msg00073.txt.bz2 Ah, I think this is a known problem: there is gdb PR 521 that has a patch in it. http://sources.redhat.com/cgi-bin/gnatsweb.pl the patch doesn't apply to the current sources anymore, maybe you want to try downloading the current CVS gdb and see if the problem is gone. Elena Mark Crosland writes: > > The symptoms I am experiencing are long before the program is run, > dlopen() has not been called yet my my program. > > gdb program > break main (it don't come back, at least not after 15 minutes) > > Below is a stack trace. I generated the stack trace by doing the following > steps > > started gdb "gdb myProgram" > > gdb prompt comes back right away and I enter "break main" > > after 15 minutes it still has not come back from "break main", CPU is > peaked by GDB > > kill -7 the GDB process to get a GDB core > > gdb'ed GDB "gdb gdb core" > > "where" to get the backtrace > > # ~/gdb/gdb ~/gdb/gdb core > GNU gdb 5.2.1 > Copyright 2002 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "sparc-sun-solaris2.8"... > Core was generated by `/homedir/markc/gdb/gdb > /vob/reactor/dist/bin32/test32'. > Program terminated with signal 7, Emulation trap. > Reading symbols from /usr/lib/libcurses.so.1...done. > Loaded symbols for /usr/lib/libcurses.so.1 > Reading symbols from /usr/lib/libsocket.so.1...done. > Loaded symbols for /usr/lib/libsocket.so.1 > Reading symbols from /usr/lib/libnsl.so.1...done. > Loaded symbols for /usr/lib/libnsl.so.1 > Reading symbols from /usr/lib/libdl.so.1...done. > Loaded symbols for /usr/lib/libdl.so.1 > Reading symbols from /usr/lib/libm.so.1...done. > Loaded symbols for /usr/lib/libm.so.1 > Reading symbols from /usr/lib/libc.so.1...done. > Loaded symbols for /usr/lib/libc.so.1 > Reading symbols from /usr/lib/libmp.so.2...done. > Loaded symbols for /usr/lib/libmp.so.2 > Reading symbols from > /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1... > done. > Loaded symbols for /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1 > Reading symbols from /usr/lib/libthread_db.so.1...done. > Loaded symbols for /usr/lib/libthread_db.so.1 > Reading symbols from > /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2... > done. > Loaded symbols for /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2 > #0 0xff1e0708 in exit () > from /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1 > (gdb) where > #0 0xff1e0708 in exit () > from /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1 > #1 0x00075fe0 in finish_cv_type (type=0xb75de0) > at /homedir/markc/gdb/gdb-5.2.1/gdb/gdbtypes.c:510 > #2 0x000fda40 in read_struct_type (pp=0xffbedba0, type=0xb75de0, > objfile=0x2d67f0) at /homedir/markc/gdb/gdb-5.2.1/gdb/stabsread.c:4211 > #3 0x000fb74c in read_type (pp=0xffbedba0, objfile=0x2d67f0) > at /homedir/markc/gdb/gdb-5.2.1/gdb/stabsread.c:2814 > #4 0x000f97f4 in define_symbol (valu=0, > string=0x1
, desc=0, type=128, > objfile=0x2d67f0) > at /homedir/markc/gdb/gdb-5.2.1/gdb/stabsread.c:2004 > #5 0x000e4c9c in process_one_symbol (type=128, desc=0, valu=0, > name=0x459f15 "map, > std::allocator > >,systemCore::logFacility*(*)(systemCore::logFacilityArgs*),std::less std::char_traits, std::allo"..., > section_offsets=0x2a1ff8, objfile=0x2d67f0) > at /homedir/markc/gdb/gdb-5.2.1/gdb/dbxread.c:3208 > #6 0x000e48e8 in read_ofile_symtab (pst=0xa34878) > at /homedir/markc/gdb/gdb-5.2.1/gdb/dbxread.c:2602 > #7 0x000e443c in dbx_psymtab_to_symtab_1 (pst=0xa34878) > at /homedir/markc/gdb/gdb-5.2.1/gdb/dbxread.c:2430 > #8 0x000e4534 in dbx_psymtab_to_symtab (pst=0xa34878) > at /homedir/markc/gdb/gdb-5.2.1/gdb/dbxread.c:2471 > #9 0x000562e0 in psymtab_to_symtab (pst=0xa34878) > at /homedir/markc/gdb/gdb-5.2.1/gdb/symfile.c:374 > #10 0x00051d90 in find_pc_sect_symtab (pc=124320, section=0x2b6ec8) > at /homedir/markc/gdb/gdb-5.2.1/gdb/symtab.c:1490 > #11 0x00050aa4 in lookup_symbol_aux (name=0xffbee000 "main", block=0x0, > namespace=VAR_NAMESPACE, is_a_field_of_this=0x0, symtab=0xffbee014) > at /homedir/markc/gdb/gdb-5.2.1/gdb/symtab.c:741 > #12 0x0005084c in lookup_symbol (name=0xffbee000 "main", block=0x0, > namespace=VAR_NAMESPACE, is_a_field_of_this=0x0, symtab=0xffbee014) > at /homedir/markc/gdb/gdb-5.2.1/gdb/symtab.c:603 > #13 0x0005d2e8 in decode_line_1 (argptr=0xffbee1c4, funfirstline=1, > default_symtab=0x0, default_line=0, canonical=0xffbee15c) > at /homedir/markc/gdb/gdb-5.2.1/gdb/linespec.c:1188 > #14 0x000c0eb8 in parse_breakpoint_sals (address=0xffbee1c4, > sals=0xffbee168, > addr_string=0xffbee15c) > at /homedir/markc/gdb/gdb-5.2.1/gdb/breakpoint.c:4477 > #15 0x000c0f5c in break_command_1 (arg=0x24827a "", flag=0, from_tty=1) > at /homedir/markc/gdb/gdb-5.2.1/gdb/breakpoint.c:4561 > #16 0x0011cb00 in do_cfunc (c=0x24df78, args=0x248276 "main", from_tty=0) > at /homedir/markc/gdb/gdb-5.2.1/gdb/cli/cli-decode.c:50 > #17 0x000b0748 in execute_command (p=0x248279 "n", from_tty=1) > at /homedir/markc/gdb/gdb-5.2.1/gdb/top.c:715 > #18 0x0006cddc in command_handler (command=0x248270 "break main") > at /homedir/markc/gdb/gdb-5.2.1/gdb/event-top.c:504 > #19 0x0006d30c in command_line_handler (rl=0x258d00 "break main") > at /homedir/markc/gdb/gdb-5.2.1/gdb/event-top.c:802 > #20 0x0019467c in rl_callback_read_char () > at /homedir/markc/gdb/gdb-5.2.1/readline/callback.c:114 > #21 0x0006c610 in rl_callback_read_char_wrapper (client_data=0x0) > at /homedir/markc/gdb/gdb-5.2.1/gdb/event-top.c:168 > #22 0x0006ccc0 in stdin_event_handler (error=443908, client_data=0x0) > at /homedir/markc/gdb/gdb-5.2.1/gdb/event-top.c:418 > #23 0x000c80b4 in handle_file_event (event_file_desc=1) > at /homedir/markc/gdb/gdb-5.2.1/gdb/event-loop.c:714 > #24 0x000c7a14 in process_event () > at /homedir/markc/gdb/gdb-5.2.1/gdb/event-loop.c:335 > #25 0x000c7a6c in gdb_do_one_event (data=0x1) > at /homedir/markc/gdb/gdb-5.2.1/gdb/event-loop.c:372 > #26 0x000b0354 in do_catch_errors (uiout=0x268740, data=0xffbee7a8) > at /homedir/markc/gdb/gdb-5.2.1/gdb/top.c:491 > #27 0x000b026c in catcher (func=0xb0344 , > func_uiout=0x268740, func_args=0xffbee7a8, func_val=0xffbee7a4, > func_caught=0xffbee7a0, errstring=0x1dc738 "", mask=6) > at /homedir/markc/gdb/gdb-5.2.1/gdb/top.c:423 > #28 0x000b038c in catch_errors (func=0xc7a30 , > func_args=0x0, errstring=0x1dc738 "", mask=6) > at /homedir/markc/gdb/gdb-5.2.1/gdb/top.c:503 > #29 0x000c7a9c in start_event_loop () > at /homedir/markc/gdb/gdb-5.2.1/gdb/event-loop.c:396 > #30 0x00038b38 in captured_command_loop (data=0x0) > at /homedir/markc/gdb/gdb-5.2.1/gdb/main.c:94 > #31 0x000b0354 in do_catch_errors (uiout=0x268740, data=0xffbeea58) > ---Type to continue, or q to quit--- > at /homedir/markc/gdb/gdb-5.2.1/gdb/top.c:491 > #32 0x000b026c in catcher (func=0xb0344 , > func_uiout=0x268740, func_args=0xffbeea58, func_val=0xffbeea54, > func_caught=0xffbeea50, errstring=0x1b0160 "", mask=6) > at /homedir/markc/gdb/gdb-5.2.1/gdb/top.c:423 > #33 0x000b038c in catch_errors (func=0x38b10 , > func_args=0x0, errstring=0x1b0160 "", mask=6) > at /homedir/markc/gdb/gdb-5.2.1/gdb/top.c:503 > #34 0x00039480 in captured_main (data=0xffbefa14) > at /homedir/markc/gdb/gdb-5.2.1/gdb/main.c:723 > #35 0x000b0354 in do_catch_errors (uiout=0x22c258, data=0xffbeede0) > at /homedir/markc/gdb/gdb-5.2.1/gdb/top.c:491 > #36 0x000b026c in catcher (func=0xb0344 , > func_uiout=0x22c258, func_args=0xffbeede0, func_val=0xffbeeddc, > func_caught=0xffbeedd8, errstring=0x1b0160 "", mask=6) > at /homedir/markc/gdb/gdb-5.2.1/gdb/top.c:423 > #37 0x000b038c in catch_errors (func=0x38b74 , > func_args=0xffbeee58, errstring=0x1b0160 "", mask=6) > at /homedir/markc/gdb/gdb-5.2.1/gdb/top.c:503 > #38 0x000397b4 in main (argc=2, argv=0xffbeeed4) > at /homedir/markc/gdb/gdb-5.2.1/gdb/main.c:734 > (gdb) > > > On Thu, 7 Nov 2002, Elena Zannoni wrote: > > > 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, > > > > > >