Re: GDB manual and @smallbook

[Brian Youmans <3diff@gnu.org>]

Thanks!

Whenever there is a finished version of the manual that you don't really
expect to change before the release, I'd like a copy, or just a pointer.
We are out of stock, and it would be good to put this into print ASAP.

- Brian Y., FSF office staff
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: binutils@sourceware.cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] libopcodes on MS-DOS
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002270903.EAA25069@indy.delorie.com>
X-SW-Source: 2000-q1/msg00378.html
Content-length: 1513

The following changes handle two problems with building libbfd on 8+3
(a.k.a. DOS) filesystems.  They get in the way when building with
DJGPP tools.

I found this while building the latest snapshot of GDB.


2000-02-26  Eli Zaretskii  <eliz@is.elta.co.il>

	* aclocal.m4 (AC_SYS_NM_PARSE): Use mconftest.$objext, not
	conftestm.$objext, since the latter overwrites conftest.$objext on
	8+3 filesystems.

	* Makefile.am (objdir): New variable, computed by running
	libtool.
	(stamp-lib): Use objdir instead of a literal .libs.

--- bfd/aclocal.m~0	Sun Aug  8 18:21:52 1999
+++ bfd/aclocal.m4	Sat Feb 26 16:25:46 2000
@@ -662,10 +662,10 @@
 #endif
 EOF
 	  # Now try linking the two files.
-	  mv conftest.$ac_objext conftestm.$ac_objext
+	  mv conftest.$ac_objext mconftest.$ac_objext
 	  ac_save_LIBS="$LIBS"
 	  ac_save_CFLAGS="$CFLAGS"
-	  LIBS="conftestm.$ac_objext"
+	  LIBS="mconftest.$ac_objext"
 	  CFLAGS="$CFLAGS$no_builtin_flag"
 	  if AC_TRY_EVAL(ac_link) && test -s conftest; then
 	    ac_pipe_works=yes


--- bfd/Makefile.a~0	Mon Feb 21 07:54:20 2000
+++ bfd/Makefile.am	Sat Feb 26 20:40:24 2000
@@ -474,10 +474,11 @@
 
 noinst_LIBRARIES = libbfd.a
 libbfd_a_SOURCES =
+objdir = `$(LIBTOOL) --config | sed -n -e s,^objdir=,,p`
 
 stamp-lib: libbfd.la
-	if [ -f .libs/libbfd.a ]; then \
-	  cp .libs/libbfd.a libbfd.tmp; \
+	if [ -f $(objdir)/libbfd.a ]; then \
+	  cp $(objdir)/libbfd.a libbfd.tmp; \
 	  $(SHELL) $(srcdir)/../move-if-change libbfd.tmp libbfd.a; \
 	else true; fi
 	touch stamp-lib
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] Make cross-compilation for the Hurd a bit more friendly
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002261349.e1QDn3604520@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00371.html
Content-length: 1742

Hi,

FYI, I checked in the following patch:


2000-02-26  Mark Kettenis  <kettenis@gnu.org>

	Make cross-compilation for the Hurd more friendly.
	From Jeff Bailey <jbailey@gnu.org>:
	* configure.in: Use AC_CHECK_TOOL to find MiG.
	* Makefile.in (MIG): New variable.
	* config/i386/i386gnu.mh (MIG): Remove.
	* configure: Regenerated.


Index: gdb/configure.in
===================================================================
RCS file: /cvs/src/src/gdb/configure.in,v
retrieving revision 1.7
diff -u -r1.7 configure.in
--- gdb/configure.in	2000/02/24 08:16:26	1.7
+++ gdb/configure.in	2000/02/26 13:31:55
@@ -77,6 +77,9 @@
 AC_CHECK_TOOL(RANLIB, ranlib, :)
 AC_PROG_YACC
 
+dnl MiG is needed for the Hurd.
+AC_CHECK_TOOL(MIG, mig)
+
 AC_ARG_PROGRAM
 
 AC_TYPE_SIGNAL
Index: gdb/Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.8
diff -u -r1.8 Makefile.in
--- gdb/Makefile.in	2000/02/24 08:16:26	1.8
+++ gdb/Makefile.in	2000/02/26 13:31:57
@@ -59,6 +59,7 @@
 RANLIB = @RANLIB@
 DLLTOOL = @DLLTOOL@
 WINDRES = @WINDRES@
+MIG = @MIG@
 
 # If the user configured GDB to include the TUI, the name of the tui
 # library goes here.
Index: gdb/config/i386/i386gnu.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386gnu.mh,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 i386gnu.mh
--- gdb/config/i386/i386gnu.mh	1999/04/16 01:34:18	1.1.1.1
+++ gdb/config/i386/i386gnu.mh	2000/02/26 13:31:57
@@ -12,7 +12,6 @@
 msg-MIGUFLAGS = -D'MSG_IMPORTS=waittime 1000;'
 
 # ick
-MIG = mig
 MIGCOM = $(MIG) -cc cat - /dev/null
 
 # Reply servers need special massaging of the code mig generates, to make
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [MAINT] Devolve responsibilities
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C84733.C86136C9@cygnus.com>
X-SW-Source: 2000-q1/msg00638.html
Content-length: 1579

Just to close this,  I've committed the attatched.

	Andrew
Fri Mar 10 11:44:55 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	* MAINTAINERS: Devolve responsibility for domain maintenance.

Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.22
diff -p -r1.22 MAINTAINERS
*** MAINTAINERS	2000/03/09 03:32:09	1.22
--- MAINTAINERS	2000/03/10 00:41:50
*************** Peter Schauer			Peter.Schauer@regent.e-t
*** 14,27 ****
  Note individuals who maintain parts of the debugger need approval to
  check in changes outside of the immediate domain that they maintain.
  
! If there is no maintainer for a given domain then the problem falls to
! the head maintainer.
  
! If there are several maintainers for a given domain then the problem
! falls to the first maintainer.  The second and third maintainers are
! firstly known to have expertise in the given domain and secondly are
! available to step in if the first maintainer is to be absent for any
! reason.
  
  
  Target/Architecture:
--- 14,25 ----
  Note individuals who maintain parts of the debugger need approval to
  check in changes outside of the immediate domain that they maintain.
  
! If there is no maintainer for a given domain then the responsibility
! falls to the head maintainer.
  
! If there are several maintainers for a given domain then
! responsibility falls to the first maintainer.  The first maintainer is
! free to devolve that responsibility among the other maintainers.
  
  
  Target/Architecture:
From dan@cgsoftware.com Sat Apr 01 00:00:00 2000
From: dan@cgsoftware.com (Daniel Berlin+list.gdb-patches)
To: Jimmy Guo <guo@cup.hp.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: patch: regression: C++ overload
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <ya796sox.fsf@dan.resnet.rochester.edu>
References: <Pine.LNX.4.10.10003231828220.10977-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-q1/msg00965.html
Content-length: 417

Jimmy Guo <guo@cup.hp.com> writes:

Yeah, i screwed that one accidently in the overload fixes, when
diagnosing the original problem.

Fixed and committed.
--Dan

> This patch fixes a regression in gdb introduced some time between 1/10
> and 3/21.  The symptom of it is unitialized memory reference in
> valops.c (find_overload_match).  This patch backs out a couple of
> bad changes.
> 
> - Jimmy Guo, guo@cup.hp.com
From shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: dan@cgsoftware.com
Cc: gdb-patches@sourceware.cygnus.com, Fernando Nasser <fnasser@cygnus.com>
Subject: Re: [RFA]: Apropos patch
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D9815A.FC4E178E@apple.com>
References: <1z52tswd.fsf@dan.resnet.rochester.edu>
X-SW-Source: 2000-q1/msg00931.html
Content-length: 961

"Daniel Berlin+list.gdb-patches" wrote:
> 
> It includes documentation, a test case (which uses a slightly weird
> regexp so it only finds one thing, and we make sure it only found one
> thing), and all the apropriate changelog entries.

You're going to hate this, but now that I see the example in the manual,
I'm wondering why "prefix:" and "command:" are on separate lines?
Why not just imitate the syntax that comes out of the help command -

	set symbol-reloading -- <help string>
	show symbol-reloading -- <help string>

Another advantage is that users can then cut-n-paste from the apropos
output more easily.

> Let me know if i can check it in, i believe it needs approval from
> Stan Shebs, and Fernando Nasser.

Just needs approval from one of us, not both!  I must confess to being
a bit mystified by the test though - why use "handle" as the match
string, and do I understand right, you're requiring that it be the
first output from apropos?

Stan
From dima@Chg.RU Sat Apr 01 00:00:00 2000
From: Dmitry Sivachenko <dima@Chg.RU>
To: kettenis@wins.uva.nl, shebs@shebs.cnchost.com
Cc: dima@Chg.RU, eliz@is.elta.co.il, gdb-patches@sourceware.cygnus.com
Subject: Re: patch for gdb.texinfo
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200001301814.VAA59965@netserv1.chg.ru>
References: <200001281909.e0SJ97M18034@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00049.html
Content-length: 2016

>
>    (Hi everybody!)
>
> Welcome back Stan!
>
>    Dmitry Sivachenko wrote:
>
>    > I think we should use new features of texinfo.  May be in future
>    > versions typeseting @env and @command will differ from the
>    > current behaviour.  By the way, FreeBSD team already updated
>    > texinfo to 4.0 in base distribution.
>
>    I disagree here.  We do have to worry about backward compatibility,
>    just as we had to support K&R compilers for a long time, and just
>    as we support many old OS versions.  Certainly many GDB users would
>    be disappointed if we trashed Linux support for any kernel older
>    than, say, 2.2.5!
>
> Well, it's slightly more complicated than that.
>
> It is standard GNU procedure to include the info files in the
> distribution.  So the user doesn't need makeinfo when building from an
> official release.  It is also standard procedure to include
> texinfo.tex in the distribution, thus for making a printed manual an
> up-to-date texinfo isn't necessary either.
>
> Thus someone who isn't actively hacking on package doesn't need texinfo at
> all.
>
> Cygnus might do things a little different.  Is GDB still distributed
> with texinfo included?  The CVS version suggests that this is the
> case.  Since the version in CVS is older than texinfo 4.0, using new
> features would not be very convenient!  Maybe it is time for an
> upgrade?  Because I think that if using new feature improves the
> markup we should try to use them.
>

Oh, I noticed /texinfo directory in your repository :).
Well, why not to upgrade texinfo there and use new texinfo commands---
no fuss, no muss...

By the way, this looks odd.  If everybody think that new commands
(@env and @command, in our case) are useless, we should write to
authors of texinfo and discuss it there.  But if these commands
do exist, why not to use them?  May be somewhere in the future,
they will be marked up differently, or W3C introduce new tag <ENV>,
which will be used when producing HTML output, etc.

--dima
From scottb@netwinder.org Sat Apr 01 00:00:00 2000
From: Scott Bambrough <scottb@netwinder.org>
To: GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: RFA: patch to gdb.base/long_long.exp
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B6A12D.5E0C35C7@netwinder.org>
X-SW-Source: 2000-q1/msg00367.html
Content-type: multipart/mixed; boundary="----------=_1583534363-29877-27"

This is a multi-part message in MIME format...

------------=_1583534363-29877-27
Content-length: 576

This test prints a long long as a double, and then compares the output to a
floating point number.  Due to the different memory layout of doubles on the ARM
it fails.  This patch special cases the test for ARM platforms.  If this is ok,
let me know and I will check it in.

2000-02-25  Scott Bambrough <scottb@netwinder.org>

	* gdb.base/long_long.exp: Correct test suite failure when printing
	a long long value as a double on ARM platforms.

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
long_long.exp.diff


------------=_1583534363-29877-27
Content-Type: text/x-diff; charset=us-ascii; name="long_long.exp.diff"
Content-Disposition: inline; filename="long_long.exp.diff"
Content-Transfer-Encoding: base64
Content-Length: 928

SW5kZXg6IGxvbmdfbG9uZy5leHANCj09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N
ClJDUyBmaWxlOiAvY3ZzL3NyYy9zcmMvZ2RiL3Rlc3RzdWl0ZS9nZGIuYmFz
ZS9sb25nX2xvbmcuZXhwLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4xLjEu
NQ0KZGlmZiAtdSAtcCAtcjEuMS4xLjUgbG9uZ19sb25nLmV4cA0KLS0tIGxv
bmdfbG9uZy5leHAJMTk5OS8wOS8xMyAyMTozODoyMwkxLjEuMS41DQorKysg
bG9uZ19sb25nLmV4cAkyMDAwLzAyLzI1IDE1OjE2OjQ0DQpAQCAtMTIxLDEx
ICsxMjEsMjAgQEAgZ2RiX3Rlc3QgInAvYyBvY3QiICIuKid3Jy4qIg0KIA0K
IGlmIHsgJHNpemVvZl9kb3VibGUgPT0gOCB9IHsNCiANCisgIGlmIFsgaXN0
YXJnZXQgImFybSotKi0qIiBdIHRoZW4gew0KKw0KKyAgICAgZ2RiX3Rlc3Qg
InAvZiBvY3QiICIuKjIuMTM4NjY3NjM1NDM4NzU1OWVcXCsyNjUuKiINCisN
CisgIH0gZWxzZSB7DQorDQogICAgIGdkYl90ZXN0ICJwL2Ygb2N0IiAiLiot
NS45ODIyNjUzNzk3NjE1NzIzZS0xMjAuKiINCiANCisgIH0NCisNCiB9IGVs
c2Ugew0KIA0KICAgICBnZGJfdGVzdCAicC9mIG9jdCIgIi4qLTIuNDI3MTYx
MjZlLTE1LioiDQorDQogfQ0KIA0KIGlmIHsgJHRhcmdldF9iaWdlbmRpYW5f
cCB9IHsNCg==

------------=_1583534363-29877-27--
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: ISO-C fixes in, please try
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C1D692.26606328@cygnus.com>
X-SW-Source: 2000-q1/msg00514.html
Content-length: 236

Hello,
I think I've eliminated all the glaring ISO-C fixes needed (there are
still many warnings but they can be flushed post 5.0).  If people had
trouble building with a non GCC ISO-C compiler, could they please
re-try.

	Andrew
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ac131313@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Add change-log variables to more MI files
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003140932.EAA28159@indy.delorie.com>
References: <38CDC788.D9C8FE12@cygnus.com>
X-SW-Source: 2000-q1/msg00688.html
Content-length: 373

> I've checked in the attatched.  It should help keep ChangeLog entries
> local.
[snip]
> + 
> + # Local variables: 
> + # change-log-default-name: "ChangeLog-mi"
> + # End: 

You _are_ aware that ChangeLog and ChangeLog-mi both map to the same
name "changelo" when truncated to 8+3 limits, right?

Is it conceivable to rename ChangeLog-mi to ChangeLog.mi or
mi-ChangeLog?
From Franz.Sirl-kernel@lauterbach.com Sat Apr 01 00:00:00 2000
From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Small testsuite fix
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <00032922114503.03866@enzo.bigblue.local>
X-SW-Source: 2000-q1/msg01110.html
Content-length: 1013

Hi,

the appended patch fixes a testsuite problem on platforms that default a char to
'unsigned char' like Linux/PPC.

Franz.

	* gdb.base/structs2.c: Support platforms defaulting to a unsigned char.


Index: gdb/testsuite/gdb.base/structs2.c
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/structs2.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 structs2.c
--- structs2.c	1999/04/16 01:34:32	1.1.1.1
+++ structs2.c	2000/03/29 20:06:15
@@ -1,6 +1,6 @@
 /* pr 13536 */
 
-static void param_reg (register char pr_char,
+static void param_reg (register signed char pr_char,
 		       register unsigned char pr_uchar,
 		       register short pr_short,
 		       register unsigned short pr_ushort);
@@ -25,7 +25,7 @@ main ()
 static void dummy () {}
 
 static void
-param_reg(register char pr_char,
+param_reg(register signed char pr_char,
 	  register unsigned char pr_uchar,
 	  register short pr_short,
 	  register unsigned short pr_ushort)
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: toddpw@windriver.com
Cc: jtc@redback.com, hjl@valinux.com, gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: A patch for ia32 hardware watchpoint.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003091328.IAA19934@indy.delorie.com>
References: <200003080845.AAA18410@alabama.wrs.com>
X-SW-Source: 2000-q1/msg00615.html
Content-length: 1307

> As far as I'm concerned, passing the breakpoint pointer is the right way
> to go; we should get away from the assumption that a target side breakpoint
> is an address with some #define'd size, and push that stuff into a default
> implementation that can be invoked easily by people writing new target
> support.

I agree.

But if we do that, I'd also suggest to leave it to the target to
decide whether a particular watchpoint fired or not.

Right now, the API presented by GDB is based solely on the address:
bpstat_stop_status calls target_stopped_data_address and does all the
decision-making based solely on that address (and some info it keeps
internally about each watchpoint).

This API is extremely limited.  Typically, the target knows much more
about the watchpoint which triggered than the generic GDB code does,
so it can make smarter decisions.  But in order to do that, the target
needs more information about the watchpoint, and it needs to pass back
to GDB the result (whether the watchpoint triggered or not), not its
address.

Btw, if we let the target decide whether a given watchpoint triggered,
we can also resolve, once and for all, all the various conflicts
between target-specific limitations of hardware-assisted watchpoints,
which now need to be dealt with on the generic level.
From jtc@redback.com Sat Apr 01 00:00:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Jim Kingdon <kingdon@redhat.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: Clean up compiler warnings
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <5mpuu87esc.fsf@jtc.redbacknetworks.com>
References: <200002071950.OAA29599@devserv.devel.redhat.com> <389F583E.65831CE5@cygnus.com>
X-SW-Source: 2000-q1/msg00089.html
Content-length: 1253

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> When switching on an enum (as in this case) I've typically
Andrew> found it better to explicitly list all cases rather than use a
Andrew> default.  That way, when a new element is added to the enum,
Andrew> the -Wswitch warning is available as a tool to the programmer
Andrew> to identify where code needs to be altered.  As an aside, that
Andrew> is why a switch on an enum rather than an if/elsif chain often
Andrew> proves more resilient to long term maintenance.

What happens when an enum gets assigned a value that's not in the set
of elements?  If there isn't a default case, we won't catch the error.

For example:

        enum foo {
                RED,
                GREEN,
                BLUE
        } foo;

        ...

        foo = 10;               /* bogus assignment */

        ...

        switch (foo) {
        case RED:
                ...; break;
        case GREEN:
                ...; break;
        case BLUE:
                ...; break;
        }

Without a default case, program flow will continue after the switch
statement.  With one, your -Wswitch trick won't work.  I'm not sure
which is worse.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From charles.gauthier@nrc.ca Sat Apr 01 00:00:00 2000
From: Charles-Antoine Gauthier <charles.gauthier@nrc.ca>
To: gdb-patches@sourceware.cygnus.com
Subject: GDB patch for 167Bug
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C42988.2AE770D7@nrc.ca>
X-SW-Source: 2000-q1/msg00546.html
Content-length: 2398

Attached is a patch to allow GDB 4.18 to write to the MVME167 through
167Bug. The MS command does not work; the MW command must be used.

The ChangeLog hunk has context from the RTEMS patches. It probably will
not apply cleanly, but it is quite short.

-- 
Charles-Antoine Gauthier
Institute for Information Technology   Institut de technologie de
l'information
National Research Council of Canada    Conseil national de recherches du
Canada
*** gdb-4.18/gdb/167bug-rom.c	Mon Mar  6 14:20:50 2000
--- ../gdb/gdb/167bug-rom.c	Mon Mar  6 14:54:42 2000
***************
*** 110,118 ****
    m167bug_cmds.clr_break =   "nobr %x\r";			/* clear a breakpoint */
    m167bug_cmds.clr_all_break =   "nobr\r";			/* clear all breakpoints */
    m167bug_cmds.fill =   "bf %x:%x %x;b\r";		/* fill (start count val) */
!   m167bug_cmds.setmem.cmdb =     "ms %x %02x\r";		/* setmem.cmdb (addr, value) */
!   m167bug_cmds.setmem.cmdw =     "ms %x %04x\r";		/* setmem.cmdw (addr, value) */
!   m167bug_cmds.setmem.cmdl =     "ms %x %08x\r";		/* setmem.cmdl (addr, value) */
    m167bug_cmds.setmem.cmdll =     NULL;			/* setmem.cmdll (addr, value) */
    m167bug_cmds.setmem.resp_delim =     NULL;			/* setreg.resp_delim */
    m167bug_cmds.setmem.term =     NULL;			/* setreg.term */
--- 110,118 ----
    m167bug_cmds.clr_break =   "nobr %x\r";			/* clear a breakpoint */
    m167bug_cmds.clr_all_break =   "nobr\r";			/* clear all breakpoints */
    m167bug_cmds.fill =   "bf %x:%x %x;b\r";		/* fill (start count val) */
!   m167bug_cmds.setmem.cmdb =     "mw %x %02x;b\r";		/* setmem.cmdb (addr, value) */
!   m167bug_cmds.setmem.cmdw =     "mw %x %04x;w\r";		/* setmem.cmdw (addr, value) */
!   m167bug_cmds.setmem.cmdl =     "mw %x %08x;l\r";		/* setmem.cmdl (addr, value) */
    m167bug_cmds.setmem.cmdll =     NULL;			/* setmem.cmdll (addr, value) */
    m167bug_cmds.setmem.resp_delim =     NULL;			/* setreg.resp_delim */
    m167bug_cmds.setmem.term =     NULL;			/* setreg.term */
*** gdb-4.18/gdb/ChangeLog	Mon Mar  6 15:38:40 2000
--- ../gdb/gdb/ChangeLog	Mon Mar  6 16:33:39 2000
***************
*** 1,3 ****
--- 1,7 ----
+ 2000-03-06 Charles-Antoine Gauthier  <charles.gauthier@nrc.ca>
+ 
+ 	* 167bug-rom.c(init_m167bug_cmds): Change the write commands.
+ 
  Fri Aug  6 165:41:15 EDT 1999 Charles-A. Gauthier <charles.gauthier@iit.nrc.ca>
  
  	* config/m68k/monitor.mt (TDEPFILES): Add 167bug-rom.o.
From scottb@netwinder.org Sat Apr 01 00:00:00 2000
From: Scott Bambrough <scottb@netwinder.org>
To: GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Re: Minor patches for ARM Linux native port...
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BADABA.56541EA7@netwinder.org>
References: <38BAD90A.FE163BDA@netwinder.org>
X-SW-Source: 2000-q1/msg00403.html
Content-length: 742

Scott Bambrough wrote:
> 
> I've checked the following patch to arm-linux-nat.c in.  This just cleans up
> some build warnings and naming of functions.

Oops.  Pushed the send button by mistake.  The patches are in
config/arm/linux.mh and config/arm/tm-linux.h.  These clean up build problems
and warnings.

> 2000-02-28  Scott Bambrough <scottb@netwinder.org>
> 
>         * config/arm/linux.mh (NATDEPFILES): Removed core-regset.o.
>         Not used.  Required to get GDB to build on glibc 2.1.3.
>         * config/arm/tm-linux.h (LOWEST_PC): Undefine LOWEST_PC
>         before redefining.  Gets rid of compiler warning.
> 

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: kettenis@wins.uva.nl
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Patch to fix thread support for Solaris x86
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002280236.VAA19189@devserv.devel.redhat.com>
References: <200002261228.NAA32377@reisser.regent.e-technik.tu-muenchen.de> <bem9ypm2a.fsf@rtl.cygnus.com> <38B9C737.BA89B057@cygnus.com> <200002280210.e1S2AdS25152@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00391.html
Content-length: 1174

> Peter's patch has a small problem (for which I am probably to blame,
> since it appears I suggested it): it conditionalizes the code on
> HAVE_I387_REGS, which according to the following comment in
> i386-tdep.c isn't right:

We got slightly tangled up on Peter's HAVE_I387_REGS patch versus
Peter's MERGEPID patch but that's minor, the point is that you are
catching all kinds of things like this, Mark, and that's why I'd love
to have you as a maintainer (speaking for myself; I guess Andrew is
working through the process so I don't want to prejudge what he ends
up with).

> I have absolutely no experience with embedded targets.  I have been
> hacking on GDB for Hurd/i386 and Linux/i386, and I do have an old i486
> with FreeBSD installed.

Sign that man up!  ('up for what' I leave as an exercise to the reader
:-)).

> I think I have a basic understanding of the most important multi-arch
> issues, but I would probably need some guidance if we ever go that
> route for x86.

Guidance should be doable.  One application for at least some amount
of multi-arch is so that a FreeBSD GDB can debug either a native
binary or a Linux binary.  I'm sure there are others.
From shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Eli Zaretskii <eliz@is.elta.co.il>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Fix texinfo problems...
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38E171AC.AB1B5AD0@apple.com>
References: <38DB1875.4B504618@cygnus.com> <38DBB937.126C95E@apple.com> <38DC6763.563424A2@cygnus.com> <200003260443.XAA26499@mescaline.gnu.org> <38E05161.9707ED26@cygnus.com> <38E1171F.7651C329@apple.com> <38E16AB4.F6081625@cygnus.com>
X-SW-Source: 2000-q1/msg01101.html
Content-length: 876

Andrew Cagney wrote:
> 
> Stan Shebs wrote:
> >
> > I didn't see your message before doing my big commit this morning,
> > so some of the changes are redundant.  I would suggest updating
> > from cvs over your patched file and seeing what's left over after
> > the merge - the remainder should be much smaller...
> 
> A patch to revert the remainder is attached.

If you could go ahead and commit these, that would be great.  Seeing
them reminds me of why I had to take out the explicit links in the
first place - they didn't play nice with the inserted readline docs,
and would have required changes that couldn't have been accepted
into standard readline.  So I slashed through the Gordian knot of
cross-links :-) by taking them all out...

(Clearly my next round of checkins should include a note to future
hackers about why the explicit links are not in there, eh?)

Stan
From shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: dan@cgsoftware.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [RFC] Better apropos patch
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D94FF8.2932EF67@apple.com>
References: <Pine.LNX.4.10.10003221307320.20082-100000@propylaea.anduin.com> <38D9429B.798F82E2@redhat.com> <wvmufwx9.fsf@dan.resnet.rochester.edu>
X-SW-Source: 2000-q1/msg00924.html
Content-length: 451

"Daniel Berlin+list.gdb-patches" wrote:

> I'll go finish commenting it, reformat it, add a changelog entry, and
> add a texinfo entry in a few minutes.

Please please please add a testcase or two also.  I suggest at the
end of gdb.base/help.exp, and lots of wildcarding in the match; but
you can count on basic commands like "break" and "print" always
being in GDB...

This apropos command *will* be really nice to have!  Thanks for adding it!

Stan
From fnasser@cygnus.com Sat Apr 01 00:00:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: RFA: Patches to configure.in and Makefile.in - varobj.c activation
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38AB216C.8C77477D@cygnus.com>
X-SW-Source: 2000-q1/msg00207.html
Content-length: 5688

ChangeLog:  configure.in:  Replaces obsolete gdbtk-variable.c with
gdbtk-varobj.c.
            configure: Regenerate.
            Makefile.in: Remove obsolete/extraneous references to
gdbtk-var* files.

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299


Index: configure.in
===================================================================
RCS file: /cvs/src/src/gdb/configure.in,v
retrieving revision 1.3
diff -c -p -r1.3 configure.in
*** configure.in        2000/02/16 13:42:25     1.3
--- configure.in        2000/02/16 22:10:46
*************** if test "${enable_gdbtk}" = "yes"; then
*** 665,673 ****
           # were in LIBS then any link tests after this point would
           # try to include things like `$(LIBGUI)', which wouldn't
work.
           GDBTKLIBS="${TCL_LIBS} ${TK_LIBS}"
!          CONFIG_SRCS="${CONFIG_SRCS} gdbtk/generic/gdbtk.c
gdbtk/generic/gdbtk-cmds.c gdbtk/generic/gdbtk-hooks.c
gdbtk/generic/gdbtk-variable.c gdbtk/generic/gdbtk-wrapper.c"
!          CONFIG_OBS="${CONFIG_OBS} gdbtk.o gdbtk-cmds.o gdbtk-hooks.o
gdbtk-variable.o gdbtk-wrapper.o"
!          CONFIG_INITS="${CONFIG_INITS} gdbtk/generic/gdbtk.c
gdbtk/generic/gdbtk-cmds.c gdbtk/generic/gdbtk-hooks.c
gdbtk/generic/gdbtk-variable.c gdbtk/generic/gdbtk-wrapper.c"
  
           if test x$gdb_cv_os_cygwin = xyes; then
              WIN32LIBS="${WIN32LIBS} -lshell32 -lgdi32 -lcomdlg32
-ladvapi32"
--- 665,673 ----
           # were in LIBS then any link tests after this point would
           # try to include things like `$(LIBGUI)', which wouldn't
work.
           GDBTKLIBS="${TCL_LIBS} ${TK_LIBS}"
!          CONFIG_SRCS="${CONFIG_SRCS} gdbtk/generic/gdbtk.c
gdbtk/generic/gdbtk-cmds.c gdbtk/generic/gdbtk-hooks.c
gdbtk/generic/gdbtk-varobj.c gdbtk/generic/gdbtk-wrapper.c"
!          CONFIG_OBS="${CONFIG_OBS} gdbtk.o gdbtk-cmds.o gdbtk-hooks.o
gdbtk-varobj.o gdbtk-wrapper.o"
!          CONFIG_INITS="${CONFIG_INITS} gdbtk/generic/gdbtk.c
gdbtk/generic/gdbtk-cmds.c gdbtk/generic/gdbtk-hooks.c
gdbtk/generic/gdbtk-varobj.c gdbtk/generic/gdbtk-wrapper.c"
  
           if test x$gdb_cv_os_cygwin = xyes; then
              WIN32LIBS="${WIN32LIBS} -lshell32 -lgdi32 -lcomdlg32
-ladvapi32"
Index: configure
===================================================================
RCS file: /cvs/src/src/gdb/configure,v
retrieving revision 1.3
diff -c -p -r1.3 configure
*** configure   2000/02/16 22:01:29     1.3
--- configure   2000/02/16 22:10:49
*************** fi
*** 6653,6661 ****
           # were in LIBS then any link tests after this point would
           # try to include things like `$(LIBGUI)', which wouldn't
work.
           GDBTKLIBS="${TCL_LIBS} ${TK_LIBS}"
!          CONFIG_SRCS="${CONFIG_SRCS} gdbtk/generic/gdbtk.c
gdbtk/generic/gdbtk-cmds.c gdbtk/generic/gdbtk-hooks.c
gdbtk/generic/gdbtk-variable.c gdbtk/generic/gdbtk-wrapper.c"
!          CONFIG_OBS="${CONFIG_OBS} gdbtk.o gdbtk-cmds.o gdbtk-hooks.o
gdbtk-variable.o gdbtk-wrapper.o"
!          CONFIG_INITS="${CONFIG_INITS} gdbtk/generic/gdbtk.c
gdbtk/generic/gdbtk-cmds.c gdbtk/generic/gdbtk-hooks.c
gdbtk/generic/gdbtk-variable.c gdbtk/generic/gdbtk-wrapper.c"
  
           if test x$gdb_cv_os_cygwin = xyes; then
              WIN32LIBS="${WIN32LIBS} -lshell32 -lgdi32 -lcomdlg32
-ladvapi32"
--- 6653,6661 ----
           # were in LIBS then any link tests after this point would
           # try to include things like `$(LIBGUI)', which wouldn't
work.
           GDBTKLIBS="${TCL_LIBS} ${TK_LIBS}"
!          CONFIG_SRCS="${CONFIG_SRCS} gdbtk/generic/gdbtk.c
gdbtk/generic/gdbtk-cmds.c gdbtk/generic/gdbtk-hooks.c
gdbtk/generic/gdbtk-varobj.c gdbtk/generic/gdbtk-wrapper.c"
!          CONFIG_OBS="${CONFIG_OBS} gdbtk.o gdbtk-cmds.o gdbtk-hooks.o
gdbtk-varobj.o gdbtk-wrapper.o"
!          CONFIG_INITS="${CONFIG_INITS} gdbtk/generic/gdbtk.c
gdbtk/generic/gdbtk-cmds.c gdbtk/generic/gdbtk-hooks.c
gdbtk/generic/gdbtk-varobj.c gdbtk/generic/gdbtk-wrapper.c"
  
           if test x$gdb_cv_os_cygwin = xyes; then
              WIN32LIBS="${WIN32LIBS} -lshell32 -lgdi32 -lcomdlg32
-ladvapi32"
Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.4
diff -c -p -r1.4 Makefile.in
*** Makefile.in 2000/02/16 04:45:41     1.4
--- Makefile.in 2000/02/16 22:10:50
*************** SFILES = ax-general.c ax-gdb.c bcache.c 
*** 431,437 ****
        kod.c kod-cisco.c \
        ui-out.c cli-out.c \
        varobj.c wrapper.c \
-       gdbtk-varobj.c \
        jv-exp.y jv-lang.c jv-valprint.c jv-typeprint.c \
        m2-exp.y m2-lang.c m2-typeprint.c m2-valprint.c main.c maint.c \
        mem-break.c minsyms.c mipsread.c nlmread.c objfiles.c parse.c \
--- 431,436 ----
*************** gdbtk-hooks.o: $(srcdir)/gdbtk/generic/g
*** 1261,1272 ****
        $(CC) -c $(INTERNAL_CFLAGS) $(IDE_CFLAGS) $(ITCL_CFLAGS)
$(TIX_CFLAGS) \
        $(TCL_CFLAGS) $(TK_CFLAGS) $(X11_CFLAGS) $(GDBTK_CFLAGS)\
                $(srcdir)/gdbtk/generic/gdbtk-hooks.c
-DGDBTK_LIBRARY=\"$(datadir)/gdbtcl\"
- 
- gdbtk-variable.o: $(srcdir)/gdbtk/generic/gdbtk-variable.c \
-       $(srcdir)/gdbtk/generic/gdbtk.h
$(srcdir)/gdbtk/generic/gdbtk-wrapper.h
-       $(CC) -c $(INTERNAL_CFLAGS) $(IDE_CFLAGS) $(ITCL_CFLAGS)
$(TIX_CFLAGS) \
-       $(TCL_CFLAGS) $(TK_CFLAGS) $(X11_CFLAGS) $(GDBTK_CFLAGS)\
-               $(srcdir)/gdbtk/generic/gdbtk-variable.c
  
  gdbtk-varobj.o: $(srcdir)/gdbtk/generic/gdbtk-varobj.c \
        $(srcdir)/gdbtk/generic/gdbtk.h \
--- 1260,1265 ----
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [MAINT/RFC] Start devolving maintenance responsibility
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BC81A0.17D25C8@cygnus.com>
X-SW-Source: 2000-q1/msg00436.html
Content-length: 3150

Hello,

GDB's been on sourceware for a whole month so its now probably time time
to start devolving more responsibility :-)
With that in mind, I'm proposing the attatched change.  It hopefully
achieves the following:

	o	allows the maintainers
		within a domain to self
		organize

	o	clearly identify who
		is ultimately responsible
		for a maintenace domain
		(where the buck stops :-)

	o	provides a suggested fraomewor
		within which domain maintainers
		can work.

Comments?  I'm going to leave this tabled for at lest a week as I know
of at least two maintainers that are off line right now.

	Andrew

Wed Mar  1 12:29:35 2000  Andrew Cagney  <cagney@b1.cygnus.com>

        * MAINTAINERS: Devolve responsibility for domain maintenance to
        the domain maintainers.
? diffs
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.88
diff -p -r1.88 ChangeLog
*** ChangeLog	2000/03/01 00:45:18	1.88
--- ChangeLog	2000/03/01 02:31:28
***************
*** 1,3 ****
--- 1,8 ----
+ Wed Mar  1 12:29:35 2000  Andrew Cagney  <cagney@b1.cygnus.com>
+ 
+ 	* MAINTAINERS: Devolve responsibility for domain maintenance to
+  	the domain maintainers.
+ 
  2000-03-01  Mark Kettenis  <kettenis@gnu.org>
  
  	* MAINTAINERS: Correct my own mail address.
Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.16
diff -p -r1.16 MAINTAINERS
*** MAINTAINERS	2000/03/01 00:45:18	1.16
--- MAINTAINERS	2000/03/01 02:31:31
*************** Stan Shebs			shebs@cygnus.com
*** 8,24 ****
  
  			Various Maintainers
  
! Note individuals who maintain parts of the debugger need approval to
! check in changes outside of the immediate domain that they maintain.
  
! If there is no maintainer for a given domain then the problem falls to
! the head maintainer.
  
! If there are several maintainers for a given domain then the problem
! falls to the first maintainer.  The second and third maintainers are
! firstly known to have expertise in the given domain and secondly are
! available to step in if the first maintainer is to be absent for any
! reason.
  
  
  Target/Architecture:
--- 8,29 ----
  
  			Various Maintainers
  
! Individuals who make changes to the debugger need approval from all
! relevant domain maintainers before those changed can be checked in.
  
! If there is no maintainer for a given maintenance domain then approval
! is the responsibility of the head maintainer.
  
! If there are several maintainers for a given maintenance domain then
! approval is the responsibility of the first maintainer.  How exactly
! that responsibility is administered is also the responsibility of the
! first maintainer.
! 
! Typically, when there are several maintainers, the first maintainer
! will devolve all responsibility for that domain to that domains
! maintainers.  Individuals making changes within their domain would
! have major changes approved through consensus (with their peers) while
! minor tweaks would not need approval.
  
  
  Target/Architecture:
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: John Wehle <john@feith.com>
Cc: cgf@cygnus.com, nsd@cygnus.com, eliz@delorie.com, jimb@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: GDB 4.17 Patch for stack aligned i386 code
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38DBE6AF.4A7B@cygnus.com>
References: <200003242200.RAA13376@jwlab.FEITH.COM>
X-SW-Source: 2000-q1/msg01004.html
Content-length: 4117

John, Eli, Jim et al, 

Nick Duffek also recently did some work related to frameless
function backtraces on the X86.  I don't know whether his 
work is checked into the main trunk.  I'd like to see him
involved in this discussion, so that we don't wind up with
two solutions to the same problem.

				Thanks,
				Michael

John Wehle wrote:
> 
> > Is it possible to tell a bit more about the problem, and how is it
> > solved?
> 
> It's desirable to omit the frame pointer when compiling leaf functions
> when targeting the x86 processor as this provides another hard register
> (%ebp) which can be used by the register allocators.  Using
> -momit-leaf-frame-pointer instructs GCC to compile code in this manner.
> Unfortunately GDB has a rather strong belief that %ebp always points to
> the frame and is unable to locate function arguments or local variables
> when the frame pointer is omitted.  The changes allow GDB to locate the
> frame based on the value in %esp.
> 
> >  Perhaps even a short test case, before and after the change?
> 
> An example is backtracing through sigtramps on Solaris (the Solaris library
> contains functions which don't use %ebp as the frame pointer).  For example
> ... the backtrace from gdb.base/a1-selftest.exp (without my patch) shows:
> 
> #0  0x80068745 in _libc_sigprocmask ()
> #1  0x80098763 in sigprocmask ()
> #2  0x8107cb3 in rl_signal_handler (sig=134509072) at signals.c:156
> #3  0x800685b1 in _sigacthandler ()
> #4  <signal handler called>
> #5  0x800682b8 in _libc_read ()
> #6  0x8101ef9 in rl_getc (stream=0x800a9ad4) at readline.c:3123
> #7  0x80ffa5b in rl_read_key () at readline.c:578
> 
> The correct backtrace is:
> 
> #0  0x80068745 in _libc_sigprocmask ()
> #1  0x80098763 in sigprocmask ()
> #2  0x8107fe7 in rl_signal_handler (sig=134509096) at signals.c:156
> #3  0x800685b1 in _sigacthandler ()
> #4  <signal handler called>
> #5  0x800682b8 in _libc_read ()
> #6  0x80098b33 in read ()
> #7  0x810222d in rl_getc (stream=0x81639a0) at readline.c:3123
> #8  0x80ffd8f in rl_read_key () at readline.c:578
> 
> > Also, do the original problems affect Solaris alone, or are they
> > common to all gcc/x86-based architectures?
> 
> They're common to all gcc/x86-based architectures.
> 
> > It's quite difficult to judge a large patch for two different problems
> > without having a more-or-less clear notion of the issues involved.
> 
> Actually they're slight variations of same problem which is how to locate
> the frame.  The GDB patch in question supports locating the frame for x86
> code:
> 
>   1) In a leaf function where the frame pointer has been omitted.  GCC
>      currently supports generating this if -momit-leaf-frame-pointer is
>      specified.  It's desirable to make this the default once debugging
>      support is in place.
> 
>   2) In a function where the frame pointer has been omitted and the stack
>      pointer is unchanging.  For example:
> 
>        int global;
> 
>        void
>        unchanging_sp(int a, int b)
>          {
> 
>          global = a + b;
>          print_global();
>          }
> 
>      I have a patch for GCC to support omitting the frame pointer in this
>      case which has been delayed pending debugger support.  It's desirable
>      to also have this as part of the default x86 code generation strategy.
> 
>   3) In a function where "andl" has been used to align the frame.  I have
>      an experimental patch for GCC to support aligning the frame in this
>      fashion in order to improve x86 floating point performance.
> 
> The original GDB work was done in November 1998 and January 1999.  I'd be
> happy to dust things off on my side in order to get these changes installed
> if you're interested in working with me.  BTW, the necessary paperwork
> is already on file.
> 
> -- John
> -------------------------------------------------------------------------
> |   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
> |    John Wehle    |     Fax: 1-215-540-5495  |                         |
> -------------------------------------------------------------------------
From nsd@cygnus.com Sat Apr 01 00:00:00 2000
From: nsd@cygnus.com
To: gdb-patches@sourceware.cygnus.com
Subject: RFA: patch to ignore C++ method conversion errors
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003302327.XAA08910@nog.bosbc.com>
X-SW-Source: 2000-q1/msg01132.html
Content-length: 3043

Hi,

When GDB tries to handle a command like "call foo.method()", it walks
through foo's methods, calling check_stub_method() on each method until
finding one with the correct prototype.

check_stub_method() calls parse_and_eval_type(), which calls error() if it
encounters any surprises.  As a result, "call foo.method()" can fail due
to problems with some other method in the same class.

For example, if a program containing the following is compiled with STABS
info and a non-debugging libstdc++:

  #include <iostream>

  class Foo {
  public:
    void method1(ostream *);
    void method2();
  } foo;

then "ostream" isn't present in the STABS symbol table, which makes "call
foo.method2()" fail with the following error:

   No symbol "ostream" in current context.

Here's a simple fix which wraps the parse_and_eval_type() call within
catch_errors() and disables error messages during that call.

There are no regressions on sparc-sun-solaris2.5.1.  It actually seems to
fix a pthreads regression; I haven't investigated why.

Okay to apply this, Dan?

Nick Duffek
nsd@cygnus.com

[patch follows]

Index: gdbtypes.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.c,v
retrieving revision 1.6
diff -u -r1.6 gdbtypes.c
--- gdbtypes.c	2000/03/28 02:25:14	1.6
+++ gdbtypes.c	2000/03/29 20:00:39
@@ -1422,6 +1422,56 @@
 #undef ADD_EXTRA
 /* End of new code added to support parsing of Cfront stabs strings */
 
+/* safe_parse_type_stub() args and return val. */
+
+struct safe_parse_type_args
+  {
+    char *p;
+    int length;
+    struct type *type;
+  };
+
+/* catch_errors() stub for safe_parse_type(). */
+
+static int
+safe_parse_type_stub (void *argsv)
+{
+  struct safe_parse_type_args *args = (struct safe_parse_type_args *)argsv;
+  args->type = parse_and_eval_type (args->p, args->length);
+  return 1;
+}
+
+/* Restore context saved by safe_parse_type. */
+
+static void
+safe_parse_cleanup (void *gdb_stderrv)
+{
+  ui_file_delete (gdb_stderr);
+  gdb_stderr = (struct ui_file *)gdb_stderrv;
+}
+
+/* Parse a type expression in the string [P..P+LENGTH).  If an error occurs,
+   silently return builtin_type_void. */
+
+static struct type *
+safe_parse_type (char *p, int length)
+{
+  struct safe_parse_type_args args;
+  struct cleanup *cleanup;
+
+  args.p = p;
+  args.length = length;
+  cleanup = make_cleanup (safe_parse_cleanup, gdb_stderr);
+  gdb_stderr = ui_file_new ();
+
+  if (!catch_errors (safe_parse_type_stub, &args, "", RETURN_MASK_ERROR))
+    args.type = builtin_type_void;
+
+  do_cleanups (cleanup);
+
+  return args.type;
+}
+
 /* Ugly hack to convert method stubs into method types.
 
    He ain't kiddin'.  This demangles the name of the method into a string
@@ -1496,7 +1546,7 @@
 	      if (strncmp (argtypetext, "...", p - argtypetext) != 0)
 		{
 		  argtypes[argcount] =
-		    parse_and_eval_type (argtypetext, p - argtypetext);
+		    safe_parse_type (argtypetext, p - argtypetext);
 		  argcount += 1;
 		}
 	      argtypetext = p + 1;
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] MAINTAINERS - more additions
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B0E127.1856849A@cygnus.com>
References: <38B08387.E542855@cygnus.com> <bd7prqdqf.fsf@rtl.cygnus.com>
X-SW-Source: 2000-q1/msg00269.html
Content-length: 1103

Jim Kingdon wrote:
> 
> > per an earlier posting, I've committed the following.
> 
> Thanks; I have committed the following (on the theory that a lead
> maintainer, in this case for web pages, gets to set policies for that
> area):

In general no.  I'd expect it to be put forward for discussion.
However, here I was clearly baiting you and you've fallen for my trap
:-)

	Andrew


> 2000-02-21  Jim Kingdon  <kingdon@redhat.com>
> 
>         * MAINTAINERS (Misc): Clarify that yes, anyone can edit web pages.
> 
> Index: MAINTAINERS
> ===================================================================
> RCS file: /cvs/src/src/gdb/MAINTAINERS,v
> retrieving revision 1.7
> retrieving revision 1.8
> diff -u -r1.7 -r1.8
> --- MAINTAINERS 2000/02/21 00:15:55     1.7
> +++ MAINTAINERS 2000/02/21 06:13:23     1.8
> @@ -101,7 +101,7 @@
>  Misc:
> 
>  Web pages.             Jim Kingdon             kingdon@redhat.com
> -                       (but apparently anyone can tweek stuff?)
> +                       (anyone can edit; kingdon is just lead maintainer)
>  Makefile.in, configure*        ALL
> 
>
From rearnsha@arm.com Sat Apr 01 00:00:00 2000
From: Richard Earnshaw <rearnsha@arm.com>
To: Nick Clifton <nickc@cygnus.com>
Cc: rearnsha@arm.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Add support for WinCE toolchains 
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002230958.JAA27935@cam-mail2.cambridge.arm.com>
References: <200002222350.PAA09035@elmo.cygnus.com>
X-SW-Source: 2000-q1/msg00330.html
Content-length: 821

> Hi J.T.
> 
> : >>>>> "Nick" == Nick Clifton <nickc@cygnus.com> writes:
> : Nick> May I have permission to apply the following patch please ?  It adds
> : Nick> support for toolchains which are targeted at Microsoft's WinCE
> : Nick> execution environment.  For the moment this means the sh-pe, mips-pe
> : Nick> and arm-wince-pe toolchains.
> : 
> : Perhaps a stupid question, but why are the sh and mips winCE ports
> : <arch>-pe, while the arm port is arm-wince-pe?
> 
> Because there is another arm-pe port already in existance which is
> incompatible with the WinCE binaries.  Thus if you configure with
> --target=arm-pe you will get a different toolchain to configuring with
> --target=arm-wince-pe.
> 
> Cheers
> 	Nick


But surely, the target should be arm-*-wince (in the same way as 
sparc-*-solaris).

R.