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: gcc 3.2, gdb 5.2.1, solaris2.8 sparc, slow



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 <Address 0x1 out of bounds>, 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::basic_string<char, std::char_traits<char>,
 > std::allocator<char>
 > >,systemCore::logFacility*(*)(systemCore::logFacilityArgs*),std::less<std::basic_string<char,
 > std::char_traits<char>, 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 <do_catch_errors>, 
 >     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 <gdb_do_one_event>, 
 >     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 <return> to continue, or q <return> to quit---
 >     at /homedir/markc/gdb/gdb-5.2.1/gdb/top.c:491
 > #32 0x000b026c in catcher (func=0xb0344 <do_catch_errors>, 
 >     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 <captured_command_loop>, 
 >     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 <do_catch_errors>, 
 >     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 <captured_main>, 
 >     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,
 > >  > > 
 > > 


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