RE: gcc 3.2, gdb 5.2.1, solaris2.8 sparc, slow

RE: gcc 3.2, gdb 5.2.1, solaris2.8 sparc, slow

[Garriss, Michael]

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,
> 

RE: gcc 3.2, gdb 5.2.1, solaris2.8 sparc, slow

[Elena Zannoni]

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,
 > > 

RE: gcc 3.2, gdb 5.2.1, solaris2.8 sparc, slow

[Mark Crosland]

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,
>  > > 
> 

Re: gcc 3.2, gdb 5.2.1, solaris2.8 sparc, slow

[Daniel Jacobowitz]

On Thu, Nov 07, 2002 at 01:17:30PM -0800, Mark Crosland wrote:
> 
> 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

> #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

This has nothing to do with slowness or with threads.  Get a current
CVS HEAD or branch snapshot and the infinite loop will be gone;
finish_cv_type no longer exists.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

RE: gcc 3.2, gdb 5.2.1, solaris2.8 sparc, slow

[Elena Zannoni]

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,
 > >  > > 
 > > 

gcc 3.2, gdb 5.2.1, solaris2.8 sparc, slow

[Mark Crosland]

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,

Re: gcc 3.2, gdb 5.2.1, solaris2.8 sparc, slow

[Mark Crosland]

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,
>