Re: Fw: GDB 5.0 won't build on GNU/Linux/sparc

[Mark Kettenis <kettenis@wins.uva.nl>]

   From: "Michael Snyder" <msnyder@cygnus.com>
   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
<sys/ucontext.h> isn't relevant for GDB.  It's the gregset_t type from
<sys/procfs.h> 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 <sys/procfs.h> (just as the
<sys/ucontext.h> 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 <msnyder@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
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 <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
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  <cagney@b1.cygnus.com>
> 
>         * 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 <cgf@cygnus.com>
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 <cgf@cygnus.com>

        * 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 <sys/procfs.h> 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 <ac131313@cygnus.com>
To: Chris Faylor <cgf@cygnus.com>
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 <cgf@cygnus.com>
> 
>         * 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 <cgf@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
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 <cgf@cygnus.com>
>> 
>>         * 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 <kettenis@wins.uva.nl>
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  <kettenis@gnu.org>

	* 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  <msnyder@seadog.cygnus.com>

        * 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  <msnyder@seadog.cygnus.com>

        * 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 <cgf@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>, 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 <cgf@cygnus.com>
>>> 
>>>         * 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 <dan@cgsoftware.com>
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: <Pine.LNX.4.10.10006022025250.14879-100000@propylaea.anduin.com>
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