From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: msnyder@cygnus.com Cc: gdb-patches@sourceware.cygnus.com, aoliva@cygnus.com Subject: Re: Fw: GDB 5.0 won't build on GNU/Linux/sparc Date: Thu, 01 Jun 2000 17:32:00 -0000 Message-id: <200006020032.e520Wf400801@delius.kettenis.local> References: <001701bfcc1e$ec7ccbb0$22295dc6@snyder.cygnus.com> X-SW-Source: 2000-06/msg00013.html From: "Michael Snyder" Date: Thu, 1 Jun 2000 16:12:56 -0700 >Alexandre Oliva wrote in message ... >>gdb/sparc-tdep.c contains code in supply_gregset() and fill_gregset() >>that will only compile on Solaris/sparc. glibc doesn't define >>prgreg_t, R_I7, R_PS, R_PC, R_nPC nor R_Y. In fact, registers from i0 >>to i7 aren't even available in glibc's gregset > >Hmmm... now that I think about it... > >Alexandre, is this (linux/sparc) a new port? sparc-tdep.c has always >contained unprotected references to prgregset_t, R_nPC and R_Y. >I don't quite understand why this problem hasn't shown up before now. > >Of course, if your port doesn't use supply_gregset etc., then there's no >problem with you ifdeffing it out as you have suggested (by undefining >USE_PROC_FS). > The gregset_t confusion strikes again :-( The gregset_t type in isn't relevant for GDB. It's the gregset_t type from that folks should be looking at in this context, or rather the elf_gregset_t from asm/elf.h. Then you'll see that i0 to i7 *are* available, at least in core dumps, and that the layout of the core-dumps is very similar to Solaris. However, the ptrace interface seems to be a little different. The gregset_t type should be removed from (just as the include) and only the prgregset_t (and perhaps elf_gregset_t) type should be made available from it. I think supply_gregset() and friends are necessary for the new threads support, and that the copies from sparc-tdep.c could be used on Linux for that. But the person who's going to fix the GDB Linux/Sparc port should first clean up the gregset_t mess, otherwise it'll drive him/her crazy. Mark >From msnyder@cygnus.com Thu Jun 01 18:33:00 2000 From: Michael Snyder To: Mark Kettenis Cc: gdb-patches@sourceware.cygnus.com, aoliva@cygnus.com Subject: Re: Fw: GDB 5.0 won't build on GNU/Linux/sparc Date: Thu, 01 Jun 2000 18:33:00 -0000 Message-id: <39370E33.5370@cygnus.com> References: <001701bfcc1e$ec7ccbb0$22295dc6@snyder.cygnus.com> <200006020032.e520Wf400801@delius.kettenis.local> X-SW-Source: 2000-06/msg00014.html Content-length: 504 Mark Kettenis wrote: > I think supply_gregset() and friends are necessary for the new threads > support, and that the copies from sparc-tdep.c could be used on Linux > for that. But the person who's going to fix the GDB Linux/Sparc port > should first clean up the gregset_t mess, otherwise it'll drive > him/her crazy. Well, you've seen my recent clean-up. Could this be resolved by using gdb_gregset_t in these functions, and typedeffing that to elf_gregset_t in the appropriate Linux header file? >From ac131313@cygnus.com Thu Jun 01 19:14:00 2000 From: Andrew Cagney To: GDB Patches Subject: Re: [rfc] multiarch TARGET_SINGLE_FORMAT et al Date: Thu, 01 Jun 2000 19:14:00 -0000 Message-id: <39371859.BFA534D7@cygnus.com> References: <39336234.665BFCD@cygnus.com> X-SW-Source: 2000-06/msg00015.html Content-length: 1102 Andrew Cagney wrote: > Tue May 30 13:31:57 2000 Andrew Cagney > > * defs.h (TARGET_FLOAT_FORMAT, TARGET_DOUBLE_FORMAT, > TARGET_LONG_DOUBLE_FORMAT): Delete. > > * gdbarch.sh: Add support for parameterized expressions. > (TARGET_FLOAT_FORMAT, TARGET_DOUBLE_FORMAT, > TARGET_LONG_DOUBLE_FORMAT): Add. Include "floatformat.h". > * gdbarch.h, gdbarch.c: Regenerate. > > * arch-utils.c (default_single_format, default_double_format, > default_long_double_format): New functions. Include > "floatformat.h" > * arch-utils.h: Declare. > > * d10v-tdep.c (d10v_gdbarch_init): Set floating point format. > Note that long double is 64 bit, the rest are 32 bit. Include > "floatformat.h". FYI, I've checked this in. Various host target maintainers may want to keep an eye on their FP test results. If things start to go wrong you should have a fairly good idea who the principal suspect is. As for the other floatformat_* changes. I've moved them to TODO. Andrew >From cgf@cygnus.com Thu Jun 01 19:21:00 2000 From: Chris Faylor To: gdb-patches@sourceware.cygnus.com Subject: [RFA] patch to solve libiberty strsignal changes (plus a minor cross-compilation fix) Date: Thu, 01 Jun 2000 19:21:00 -0000 Message-id: <20000601222133.A20052@cygnus.com> References: <20000531182910.A29100@cygnus.com> <200006010604.CAA09992@indy.delorie.com> <20000601021247.A13381@cygnus.com> X-SW-Source: 2000-06/msg00016.html Content-length: 3555 Following Andrew's suggestions, I submit the following for approval. This patch adds checks for strsignal in string.h and strings.h, moves the strsignal declaration from defs.h into gdb_string.h and adds a NEED_DECLARATION_STRSIGNAL to config.in . This patch also includes what I hope is a no-brainer fix to find the correct versions of windres and ranlib (aka i686-pc-cygwin-windres and i686-pc-cygwin-ranlib) when cross compiling. cgf Thu Jun 1 22:11:19 2000 Christopher Faylor * configure.in: Check for declaration of strsignal in string{,s}.h. Detect correct versions of ranlib and windres when cross-compiling. * configure: Regenerate. * config.in: Define NEED_DECLARATION_STRSIGNAL if strsignal is not declared in system header file. * defs.h: Move strsignal declaration into gdb_string.h. * gdb_string.h: Declare strsignal here if if isn't declared anywhere else. Index: configure.in =================================================================== RCS file: /cvs/src/src/gdb/configure.in,v retrieving revision 1.29 diff -u -p -r1.29 configure.in --- configure.in 2000/05/26 04:11:34 1.29 +++ configure.in 2000/06/02 02:15:26 @@ -78,6 +78,8 @@ AC_PROG_AWK AC_PROG_INSTALL AC_CHECK_TOOL(AR, ar) AC_CHECK_TOOL(RANLIB, ranlib, :) +AC_CHECK_TOOL(DLLTOOL, dlltool) +AC_CHECK_TOOL(WINDRES, windres) AC_PROG_YACC dnl MiG is needed for the Hurd. @@ -168,6 +170,11 @@ BFD_NEED_DECLARATION(strerror) BFD_NEED_DECLARATION(strdup) BFD_NEED_DECLARATION(strstr) +AC_EGREP_HEADER(strsignal, string.h, , [ + AC_EGREP_HEADER(strsignal, strings.h, , [ +AC_DEFINE(NEED_DECLARATION_STRSIGNAL) +]) +]) # The following save_state_t checkery is only necessary for HPUX # versions earlier than 10.20. When those fade from memory, this @@ -606,11 +613,6 @@ AC_CACHE_CHECK([for cygwin], gdb_cv_os_c #if defined (__CYGWIN__) || defined (__CYGWIN32__) lose #endif],[gdb_cv_os_cygwin=yes],[gdb_cv_os_cygwin=no])]) - -DLLTOOL=${DLLTOOL-dlltool} -WINDRES=${WINDRES-windres} -AC_SUBST(DLLTOOL) -AC_SUBST(WINDRES) dnl Figure out which term library to use. if test x$gdb_host = xgo32; then Index: config.in =================================================================== RCS file: /cvs/src/src/gdb/config.in,v retrieving revision 1.12 diff -u -p -r1.12 config.in --- config.in 2000/05/26 04:11:34 1.12 +++ config.in 2000/06/02 02:15:26 @@ -399,3 +399,5 @@ /* Define if has psaddr_t. */ #undef HAVE_PSADDR_T +/* Define if have strsignal definition in string.h. */ +#undef NEED_DECLARATION_STRSIGNAL Index: defs.h =================================================================== RCS file: /cvs/src/src/gdb/defs.h,v retrieving revision 1.22 diff -u -p -r1.22 defs.h --- defs.h 2000/06/02 01:59:13 1.22 +++ defs.h 2000/06/02 02:15:27 @@ -56,9 +56,6 @@ #include "libiberty.h" -/* libiberty.h can't declare this one, but evidently we can. */ -extern char *strsignal (int); - #include "progress.h" #ifdef USE_MMALLOC Index: gdb_string.h =================================================================== RCS file: /cvs/src/src/gdb/gdb_string.h,v retrieving revision 1.2 diff -u -p -r1.2 gdb_string.h --- gdb_string.h 2000/05/28 01:12:27 1.2 +++ gdb_string.h 2000/06/02 02:15:27 @@ -68,4 +68,9 @@ extern char *strstr (const char *, const #endif #endif +#ifdef NEED_DECLARATION_STRSIGNAL +/* libiberty.h can't declare this one, but evidently we can. */ +extern char *strsignal (int); +#endif + #endif /* !defined(GDB_STRING_H) */ >From ac131313@cygnus.com Thu Jun 01 20:08:00 2000 From: Andrew Cagney To: Chris Faylor Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [RFA] patch to solve libiberty strsignal changes (plus a minor cross-compilation fix) Date: Thu, 01 Jun 2000 20:08:00 -0000 Message-id: <393724EA.2C034823@cygnus.com> References: <20000531182910.A29100@cygnus.com> <200006010604.CAA09992@indy.delorie.com> <20000601021247.A13381@cygnus.com> <20000601222133.A20052@cygnus.com> X-SW-Source: 2000-06/msg00017.html Content-length: 1217 Chris Faylor wrote: > > Following Andrew's suggestions, I submit the following for approval. > > This patch adds checks for strsignal in string.h and strings.h, moves the > strsignal declaration from defs.h into gdb_string.h and adds a > NEED_DECLARATION_STRSIGNAL to config.in . > > This patch also includes what I hope is a no-brainer fix to find the > correct versions of windres and ranlib (aka i686-pc-cygwin-windres and > i686-pc-cygwin-ranlib) when cross compiling. > > cgf > > Thu Jun 1 22:11:19 2000 Christopher Faylor > > * configure.in: Check for declaration of strsignal in string{,s}.h. > Detect correct versions of ranlib and windres when cross-compiling. > * configure: Regenerate. > * config.in: Define NEED_DECLARATION_STRSIGNAL if strsignal is not > declared in system header file. > * defs.h: Move strsignal declaration into gdb_string.h. > * gdb_string.h: Declare strsignal here if if isn't declared anywhere > else. Chris, I'm fairly sure that GDB simply shouldn't be calling strsignal(). lowcore.c should use the target signal to string function while the others are going to be made obsolete. Andrew >From cgf@cygnus.com Fri Jun 02 08:21:00 2000 From: Chris Faylor To: Andrew Cagney Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [RFA] patch to solve libiberty strsignal changes (plus a minor cross-compilation fix) Date: Fri, 02 Jun 2000 08:21:00 -0000 Message-id: <20000602112110.A1020@cygnus.com> References: <20000531182910.A29100@cygnus.com> <200006010604.CAA09992@indy.delorie.com> <20000601021247.A13381@cygnus.com> <20000601222133.A20052@cygnus.com> <393724EA.2C034823@cygnus.com> X-SW-Source: 2000-06/msg00018.html Content-length: 1512 On Fri, Jun 02, 2000 at 01:07:22PM +1000, Andrew Cagney wrote: >Chris Faylor wrote: >> >> Following Andrew's suggestions, I submit the following for approval. >> >> This patch adds checks for strsignal in string.h and strings.h, moves the >> strsignal declaration from defs.h into gdb_string.h and adds a >> NEED_DECLARATION_STRSIGNAL to config.in . >> >> This patch also includes what I hope is a no-brainer fix to find the >> correct versions of windres and ranlib (aka i686-pc-cygwin-windres and >> i686-pc-cygwin-ranlib) when cross compiling. >> >> cgf >> >> Thu Jun 1 22:11:19 2000 Christopher Faylor >> >> * configure.in: Check for declaration of strsignal in string{,s}.h. >> Detect correct versions of ranlib and windres when cross-compiling. >> * configure: Regenerate. >> * config.in: Define NEED_DECLARATION_STRSIGNAL if strsignal is not >> declared in system header file. >> * defs.h: Move strsignal declaration into gdb_string.h. >> * gdb_string.h: Declare strsignal here if if isn't declared anywhere >> else. > >I'm fairly sure that GDB simply shouldn't be calling strsignal(). >lowcore.c should use the target signal to string function while the >others are going to be made obsolete. Ok. That doesn't help much with my current problem, though. How do I build a Windows version of gdb? I don't think you want me to be making changes to places like lowcore.c. I'm really not qualified for that... cgf >From kettenis@wins.uva.nl Fri Jun 02 12:06:00 2000 From: Mark Kettenis To: gdb-patches@sourceware.cygnus.com Subject: [PATCH] FreeBSD/Alpha fix Date: Fri, 02 Jun 2000 12:06:00 -0000 Message-id: <200006021906.e52J6Bk00378@delius.kettenis.local> X-SW-Source: 2000-06/msg00019.html Content-length: 876 Looks like my check-in of the FreeBSD/Alpha support was a bit premature :-(. Fixed now. Mark 2000-06-02 Mark Kettenis * alphabsd-nat.c (supply_fpregset): Substract FP0_REGNUM from register number when used as index into fpr_regs array. Index: alphabsd-nat.c =================================================================== RCS file: /cvs/src/src/gdb/alphabsd-nat.c,v retrieving revision 1.1 diff -u -p -r1.1 alphabsd-nat.c --- alphabsd-nat.c 2000/05/31 20:26:46 1.1 +++ alphabsd-nat.c 2000/06/02 19:03:32 @@ -101,7 +101,7 @@ supply_fpregset (fpregset_t *fpregsetp) if (CANNOT_FETCH_REGISTER (i)) supply_register (i, NULL); else - supply_register (i, (char *) &fpregsetp->fpr_regs[i]); + supply_register (i, (char *) &fpregsetp->fpr_regs[i - FP0_REGNUM]); } supply_register (FPCR_REGNUM, (char *) &fpregsetp->fpr_cr); >From msnyder@cygnus.com Fri Jun 02 14:41:00 2000 From: msnyder@cygnus.com To: gdb-patches@sourceware.cygnus.com Cc: ezannoni@cygnus.com, fnasser@cygnus.com Subject: [PATCH]: Loosen up annota1.exp test. Date: Fri, 02 Jun 2000 14:41:00 -0000 Message-id: <200006022141.OAA14895@seadog.cygnus.com> X-SW-Source: 2000-06/msg00020.html Content-length: 2961 This test often fails because different targets behave slightly differently. I'm making the regular expression more flexible, so that it does not care how many times the target calls flush_cached_frames() or breakpoints_invalid(). 2000-06-02 Michael Snyder * gdb.base/annota1.exp (run until main breakpoint): Loosen up the regular expression: accept an (almost) arbitrary sequence of "frames-invalid" and "breakpoints-invalid" messages both before and after the "starting" message. Index: annota1.exp =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.base/annota1.exp,v retrieving revision 1.2 diff -p -r1.2 annota1.exp *** annota1.exp 2000/05/24 17:14:50 1.2 --- annota1.exp 2000/06/02 21:37:20 *************** gdb_expect { *** 142,152 **** # #exp_internal 1 send_gdb "run\n" ! gdb_expect { ! -re "\r\n\032\032post-prompt\r\nStarting program: $binfile \(\r\n\r\n\032\032frames-invalid\)+\(\r\n\r\n\032\032breakpoints-invalid\)*.*\(\r\n\r\n\032\032frames-invalid\)*\r\n\r\n\032\032starting\(\r\n\r\n\032\032frames-invalid\)+\r\n\r\n\032\032breakpoint 1\r\n\r\nBreakpoint 1, \r\n\032\032frame-begin 0 $hex\r\n\r\n\032\032frame-function-name\r\nmain\r\n\032\032frame-args\r\n \\(\\)\r\n\032\032frame-source-begin\r\n at \r\n\032\032frame-source-file\r\n.*annota1.c\r\n\032\032frame-source-file-end\r\n:\r\n\032\032frame-source-line\r\n$main_line\r\n\032\032frame-source-end\r\n\r\n\r\n\032\032source.*$srcfile:$main_line:.*:beg:$hex\r\n\r\n\032\032frame-end\r\n\r\n\032\032stopped\r\n.*$gdb_prompt$" \ ! { pass "run until main breakpoint" } ! -re ".*$gdb_prompt$" { fail "run until main breakpoint" } ! timeout { fail "run until main breakpoint (timeout)" } } #exp_internal 0 #exit 0 --- 142,157 ---- # #exp_internal 1 send_gdb "run\n" ! gdb_expect { ! -re "\r\n\032\032post-prompt\r\nStarting program: $binfile \(\r\n\r\n\032\032frames-invalid\)+\(\(\r\n\r\n\032\032frames-invalid\)|\(\r\n\r\n\032\032breakpoints-invalid\)\)*\r\n\r\n\032\032starting\(\r\n\r\n\032\032frames-invalid\)+\(\(\r\n\r\n\032\032frames-invalid\)|\(\r\n\r\n\032\032breakpoints-invalid\)\)*\r\n\r\n\032\032breakpoint 1\r\n\r\nBreakpoint 1, \r\n\032\032frame-begin 0 $hex\r\n\r\n\032\032frame-function-name\r\nmain\r\n\032\032frame-args\r\n \\(\\)\r\n\032\032frame-source-begin\r\n at \r\n\032\032frame-source-file\r\n.*annota1.c\r\n\032\032frame-source-file-end\r\n:\r\n\032\032frame-source-line\r\n$main_line\r\n\032\032frame-source-end\r\n\r\n\r\n\032\032source.*$srcfile:$main_line:.*:beg:$hex\r\n\r\n\032\032frame-end\r\n\r\n\032\032stopped.*$gdb_prompt$" { ! pass "run until main breakpoint" ! } ! -re ".*$gdb_prompt$" { ! fail "run until main breakpoint" ! } ! timeout { ! fail "run until main breakpoint (timeout)" ! } } #exp_internal 0 #exit 0 >From msnyder@cygnus.com Fri Jun 02 15:35:00 2000 From: msnyder@cygnus.com To: ezannoni@cygnus.com, fnasser@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: [PATCH]: xfail a test that never works with g++ Date: Fri, 02 Jun 2000 15:35:00 -0000 Message-id: <200006022235.PAA15092@seadog.cygnus.com> X-SW-Source: 2000-06/msg00021.html Content-length: 1369 This test was added by HP last year for use with their native compiler. A comment explains that the test never worked with gnu/gcc/g++, and the authors attempted to xfail the whole test. What they apparently didn't realize was that "xfail" only applies to the next pass/fail, not to the entire test file. 2000-06-02 Michael Snyder * gdb.c++/local.exp: This test has never been known to work with g++. Index: gdb.c++/local.exp =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.c++/local.exp,v retrieving revision 1.6 diff -p -r1.6 local.exp *** local.exp 1999/11/24 16:08:47 1.6 --- local.exp 2000/06/02 22:32:48 *************** gdb_expect { *** 130,135 **** --- 130,144 ---- timeout { fail "(timeout) ptype NestedInnerLocal" } } + # srikanth, These tests have always been run only with aCC. Now in + # the new scheme of things, we run it twice, once with aCC, and once + # with g++. Flag these tests as expected failures when run with g++. + # as these are failing now and were never known to pass with g++. + global gcc_compiled + if {$gcc_compiled} then { + setup_xfail "*-*-*" + } + # gdb incorrectly interprets the NestedInnerLocal in # InnerLocal::NestedInnerLocal as field name instead of a type name; # See CLLbs14784. >From jtc@redback.com Fri Jun 02 16:18:00 2000 From: jtc@redback.com (J.T. Conklin) To: gdb-patches@sourceware.cygnus.com Subject: FYI: more i[3456]86-*-netbsdelf* changes Date: Fri, 02 Jun 2000 16:18:00 -0000 Message-id: <5md7lzbrk4.fsf@jtc.redback.com> X-SW-Source: 2000-06/msg00022.html Content-length: 768 ELF based NetBSD/i386 systems appear to use the standard ELF ABI, so the USE_STRUCT_CONVENTION macro defined in i386/tm-nbsd.h must be overridden. * configure.tgt: Add pattern for i[3456]86-*-netbsdelf*. * config/i386/nbsdelf.mt: New file. * config/i386/tm-nbsdelf.h: New file. * config/i386/tm-nbsd.h: change include of tm-nbsd.h to the more explicit config/tm-nbsd.h. This new port now has respectible testsuite scores: === gdb Summary === # of expected passes 6164 # of unexpected failures 11 # of unexpected successes 33 # of expected failures 156 # of untested testcases 18 # of unsupported tests 1 --jtc -- J.T. Conklin RedBack Networks >From cgf@cygnus.com Fri Jun 02 21:40:00 2000 From: Chris Faylor To: Andrew Cagney , gdb-patches@sourceware.cygnus.com Subject: Re: [RFA] patch to solve libiberty strsignal changes (plus a minor cross-compilation fix) Date: Fri, 02 Jun 2000 21:40:00 -0000 Message-id: <20000603004037.A15577@cygnus.com> References: <20000531182910.A29100@cygnus.com> <200006010604.CAA09992@indy.delorie.com> <20000601021247.A13381@cygnus.com> <20000601222133.A20052@cygnus.com> <393724EA.2C034823@cygnus.com> <20000602112110.A1020@cygnus.com> X-SW-Source: 2000-06/msg00023.html Content-length: 1242 On Fri, Jun 02, 2000 at 11:21:10AM -0400, Chris Faylor wrote: >On Fri, Jun 02, 2000 at 01:07:22PM +1000, Andrew Cagney wrote: >>> Thu Jun 1 22:11:19 2000 Christopher Faylor >>> >>> * configure.in: Check for declaration of strsignal in string{,s}.h. >>> Detect correct versions of ranlib and windres when cross-compiling. >>> * configure: Regenerate. >>> * config.in: Define NEED_DECLARATION_STRSIGNAL if strsignal is not >>> declared in system header file. >>> * defs.h: Move strsignal declaration into gdb_string.h. >>> * gdb_string.h: Declare strsignal here if if isn't declared anywhere >>> else. >> >>I'm fairly sure that GDB simply shouldn't be calling strsignal(). >>lowcore.c should use the target signal to string function while the >>others are going to be made obsolete. > >Ok. That doesn't help much with my current problem, though. How do I >build a Windows version of gdb? I don't think you want me to be making >changes to places like lowcore.c. I'm really not qualified for that... FWIW, I've worked around this problem in newlib with a truly awful hack. That will at least fend off problems from cygwin users who try to build gdb. cgf >From dan@cgsoftware.com Fri Jun 02 21:47:00 2000 From: Daniel Berlin To: jtc@redback.com Cc: gdb-patches@sourceware.cygnus.com Subject: Horrible GDB symbol table performance Date: Fri, 02 Jun 2000 21:47:00 -0000 Message-id: X-SW-Source: 2000-06/msg00024.html Content-length: 5347 And i'll put money these are either java, or C++ programs, right? I had a theory a while ago most of that most of the performance problem in lookup_partial_symbol is because we can't do the binary search, or force a linear lookup, a lot of the time. So, i grabbed the first small-medium size C++ program i could find, (First thing google found on "large C++ progrram" where i could easily download the source was a social security administration application that estimates benefits.), to see if there was any chance i was right, and turned on profiling in gdb to make sure my application could get close to yours in the various percentages. Oh, i also added a few counters to gdb in lookup_partial_symbol, and a quick function to print them out, like so: [root@dan anypiab]# ../../../gdb/gdb ./anypiab GNU gdb 5.0 Copyright 2000 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 "i686-pc-linux"...info s (gdb) info sy symbol symbolstat (gdb) info symbolstat Total searches:92 Linear searches forced:84 On average, linear search goes through 21.000000 symbols to find a match. Searches we couldn't binary search:0 (gdb) Searches we couldn't binary search means the global flag is 0, so we couldn't binary search it. forced linear searches are just that. It means it's really doing a linear search, not just that the flag is set. This includes the times we had to linear search because of the global flag being 0. Obviously, the average is how many symbols the linear search went through (inside the for loop), divided by the number of linear searches we did. Hmm, already not a particularly good start, but let's do a bunch of stuff (print out variables, mainly, since i assume this is what most people do in debugging), and see what happens. (gdb) info symbolstat Total searches:4778 Linear searches forced:4518 On average, linear search goes through 155.000000 symbols to find a match. Searches we couldn't binary search:2343 Since i didn't have all the SSA datafiles it needed, i had to stop after printing out almost all of the symbols in the first 10 lines (bout 10 symbols, all of them C++ classes), stepping through calls, etc. I'd consider it a short debug session. The stats say to me, that we can't linear search because of the global flag about 50% of the time. 47% of the rest of the time, we get forced into a linear search, and search an average of 155 symbols. So we are only binary searching 3% of the time. Which is bad for performance, obviously. But hey, could just be a fluke, so let's keep going. Seeing that i needed some more data, i chose another medium size program, DDD. ~135k lines. To make a long story short, after 15 minutes of debugging, and tracking down a real crash in DDD, here are the stats: Total searches: 858210 Linear searches forced: 825302 On average, linear search goes through 2036.000000 symbols to find a match. Searches we couldn't binary search: 394732 So, we are being forced into linear search, 96% of the time, with ~40-45% of those from the global flag being 0. So 96% of the time, we end up searching through an average of 2036 symbols. That's really bad. And gprof confirms JT's results, i get 68% of my time spend in lookup_partial_symbol. So why doesn't anyone else see it? Well, we mostly debug gdb. which never will force a linear search when the global flag isn't set, since it's written in C (if your language is C++, it'll get forced into a linear search every time it can't find the symbol through a binary search) Same with gcc. So you get: (After a quick session on gcc) (gdb) info symbolstat Total searches:54100 Linear searches forced:49090 On average, linear search goes through 23.000000 symbols to find a match. Searches we couldn't binary search:49090 So while we aren't binary searching about 90% of the time, we aren't looking at that many symbols when we aren't, so we don't get hurt. What's my point? Well, basically, that the binary search being done isn't helping, because its not used, or we ignore the results, when debugging C++ programs. Just for kicks, at the expense of a ton of memory, and mainly because i could do it really quickly (using the libiberty hash table), i made it do a hash table lookup on the same data it's doing a linear search through now, and as expected, it went a bunch faster (Like, lookup_partial_symbol dropped to an absurdly low percentage of the time). Doing this properly would take more than the hundred lines or so it took for my hack (since i didn't bother to change the structure of the partial symbol tables, i just had it add it to my hash table as well), but it would certainly help. For those wondering, i did handle the namespace issue, just like it does now, so it is a valid comparison). Also interesting to note is that printing some of these variables, and members, was performing >800 partial symbol lookups a pop. That took me completely by surprise. all i did was print "argle.bargle", not something 50 levels deep. THen again, i could be completely off, it's late, and i could just not be thinking clearly. --Dan