Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Fernando Nasser <fnasser@cygnus.com>
To: Christopher Faylor <cgf@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Wed, 17 Jan 2001 13:55:00 -0000	[thread overview]
Message-ID: <3A6614B3.DCB68787@cygnus.com> (raw)
In-Reply-To: <20010117161229.B15404@redhat.com>

Christopher Faylor wrote:
> 
> On Wed, Jan 17, 2001 at 04:09:27PM -0500, Elena Zannoni wrote:
> >
> >I would like to see this in. There are too many divergences already.
> >
> >Fernando, JimI can one of you commit this?
> >
> >Unless there is some opposition from JimB. (if he replies within say,
> >5 hours :-).
> 
> Can I just suggest that we check it in now and let JimB yell if he
> disapproves?  I think enough experienced eyes have looked at this for
> there to be a very small chance that the patch is wrong.
> 

Yes, it is causing lots of trouble everywhere.  I will check it in and 
leave it for Jim Blandy to decide if it stays or is reverted.



> What does everyone think about setting a "vote system" for this kind
> of contingency?  We could say that the vote of four gdb engineers with
> write-after-approval == one maintainer with the maintainer having
> absolute authority to remove patches that they think are incorrect,
> of course.
> 

It is a good suggestion.

We do need some mechanism to deal with these cases.



-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From taylor@cygnus.com Wed Jan 17 13:57:00 2001
From: David Taylor <taylor@cygnus.com>
To: Christopher Faylor <cgf@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Wed, 17 Jan 2001 13:57:00 -0000
Message-id: <200101172157.QAA21576@texas.cygnus.com>
X-SW-Source: 2001-01/msg00164.html
Content-length: 2517

    Date: Wed, 17 Jan 2001 16:12:29 -0500
    From: Christopher Faylor <cgf@redhat.com>

    On Wed, Jan 17, 2001 at 04:09:27PM -0500, Elena Zannoni wrote:
    >
    >I would like to see this in. There are too many divergences already.
    >
    >Fernando, JimI can one of you commit this?
    >
    >Unless there is some opposition from JimB. (if he replies within say,
    >5 hours :-).

Radical Idea: You might try calling him...

[I say that because I know that several of the people participating in
this discussion have Jim's phone number.]

There is no guarantee that he will even see the discussion within 5
hours, much less have looked over the posting and approved of it.

From Jim's lack of response, I would guess that:

. he's on vacation, or

. he's not reading email, or

. he's no longer reading gdb-patches

I tried calling him and got voice mail, so it wouldn't surprise me if
he was on vacation or otherwise occupied.  I left him a message.

    Can I just suggest that we check it in now and let JimB yell if he
    disapproves?  I think enough experienced eyes have looked at this for
    there to be a very small chance that the patch is wrong.

Elena, if I'm reading the MAINTAINERS file correctly, you are a backup
maintainer for the generic symtab stuff -- so, your approval should
suffice (unless you feel uncomfortable with it and want Jim to look it
over, too).

    What does everyone think about setting a "vote system" for this kind
    of contingency?  We could say that the vote of four gdb engineers with
    write-after-approval == one maintainer with the maintainer having
    absolute authority to remove patches that they think are incorrect,
    of course.

    cgf

I don't think we need such a system.

For the generic symtab stuff, the MAINTAINERS file says that Jim
Blandy is the primary and Elena Zannoni is a backup maintainer.  So,
if Elena approved it, it can go in.  And Daniel Berlin can just check
it in.  Ditto if any "Blanket Write Privs" maintainer has approved it.

[Since any Blanket Write Privs maintainer can just check it in, I
would assume that they could also just "approve it" and then leave the
actual checkin task to the person that submitted it -- provided he/she
has checkin privileges.]

In general, I think that if a maintainer is unresponsive, then that
should be dealt with -- whether it's by politely asking him/her to be
more responsive, by nagging, by adding additional maintainers to some
areas, by replacing the maintainer, or something else.
From ezannoni@cygnus.com Wed Jan 17 14:15:00 2001
From: Elena Zannoni <ezannoni@cygnus.com>
To: David Taylor <taylor@cygnus.com>
Cc: Christopher Faylor <cgf@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Wed, 17 Jan 2001 14:15:00 -0000
Message-id: <14950.6503.362049.921003@kwikemart.cygnus.com>
References: <200101172157.QAA21576@texas.cygnus.com>
X-SW-Source: 2001-01/msg00165.html
Content-length: 2440

David Taylor writes:

 >     >Unless there is some opposition from JimB. (if he replies within say,
 >     >5 hours :-).
 > 

That was a joke!

Elena


 > Radical Idea: You might try calling him...
 > 
 > [I say that because I know that several of the people participating in
 > this discussion have Jim's phone number.]
 > 
 > There is no guarantee that he will even see the discussion within 5
 > hours, much less have looked over the posting and approved of it.
 > 
 > >From Jim's lack of response, I would guess that:
 > 
 > . he's on vacation, or
 > 
 > . he's not reading email, or
 > 
 > . he's no longer reading gdb-patches
 > 
 > I tried calling him and got voice mail, so it wouldn't surprise me if
 > he was on vacation or otherwise occupied.  I left him a message.
 > 
 >     Can I just suggest that we check it in now and let JimB yell if he
 >     disapproves?  I think enough experienced eyes have looked at this for
 >     there to be a very small chance that the patch is wrong.
 > 
 > Elena, if I'm reading the MAINTAINERS file correctly, you are a backup
 > maintainer for the generic symtab stuff -- so, your approval should
 > suffice (unless you feel uncomfortable with it and want Jim to look it
 > over, too).
 > 
 >     What does everyone think about setting a "vote system" for this kind
 >     of contingency?  We could say that the vote of four gdb engineers with
 >     write-after-approval == one maintainer with the maintainer having
 >     absolute authority to remove patches that they think are incorrect,
 >     of course.
 > 
 >     cgf
 > 
 > I don't think we need such a system.
 > 
 > For the generic symtab stuff, the MAINTAINERS file says that Jim
 > Blandy is the primary and Elena Zannoni is a backup maintainer.  So,
 > if Elena approved it, it can go in.  And Daniel Berlin can just check
 > it in.  Ditto if any "Blanket Write Privs" maintainer has approved it.
 > 
 > [Since any Blanket Write Privs maintainer can just check it in, I
 > would assume that they could also just "approve it" and then leave the
 > actual checkin task to the person that submitted it -- provided he/she
 > has checkin privileges.]
 > 
 > In general, I think that if a maintainer is unresponsive, then that
 > should be dealt with -- whether it's by politely asking him/her to be
 > more responsive, by nagging, by adding additional maintainers to some
 > areas, by replacing the maintainer, or something else.
 > 
From jtc@redback.com Wed Jan 17 15:18:00 2001
From: jtc@redback.com (J.T. Conklin)
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH]: tweak netbsd/m68k config
Date: Wed, 17 Jan 2001 15:18:00 -0000
Message-id: <5mn1cp4vjv.fsf@jtc.redback.com>
X-SW-Source: 2001-01/msg00166.html
Content-length: 5038

I have committed the enclosed patch.

Due to a missing header file, the netbsd/m68k target didn't compile.
While fixing that, I fixed structure returns and some leftover cruft 
in i386nbsd-tdep.c.

I noticed when preparing this message that I missed documenting the
change to BKP_VECTOR and REMOTE_BKP_VECTOR, so I'll be updating the
ChangeLog file accordingly.

        --jtc

001-01-17  J.T. Conklin  <jtc@redback.com>

        * config/m68k/tm-nbsd.h (USE_STRUCT_CONVENTION): Define.
        * config/m68k/nbsd.mt (TDEPFILES): Add m68knbsd-tdep.o.
        * m68knbsd-tdep.c: New file.

        * i386nbsd-tdep.c: Remove #if 0'd out #includes.

        * m68knbsd-nat.c: #include gdbcore.h.

Index: i386nbsd-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386nbsd-tdep.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -c -r1.1 -r1.2
*** i386nbsd-tdep.c	2000/09/07 20:08:40	1.1
--- i386nbsd-tdep.c	2001/01/17 23:07:15	1.2
***************
*** 21,34 ****
  
  #include "defs.h"
  #include "gdbtypes.h"
- #if 0
- #include <sys/types.h>
- #include <sys/ptrace.h>
- #include <machine/reg.h>
- #include <machine/frame.h>
- #include "inferior.h"
- #include "gdbcore.h" /* for registers_fetched() */
- #endif
  
  int
  i386nbsd_use_struct_convention (int gcc_p, struct type *type)
--- 21,26 ----
Index: config/m68k/nbsd.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/m68k/nbsd.mt,v
retrieving revision 1.4
retrieving revision 1.5
diff -c -r1.4 -r1.5
*** nbsd.mt	2000/12/08 19:46:06	1.4
--- nbsd.mt	2001/01/17 23:07:15	1.5
***************
*** 1,5 ****
  # Target: Motorola m68k running NetBSD
! TDEPFILES= m68k-tdep.o solib.o solib-svr4.o
  TM_FILE= tm-nbsd.h
  
  GDBSERVER_DEPFILES= low-nbsd.o
--- 1,5 ----
  # Target: Motorola m68k running NetBSD
! TDEPFILES= m68k-tdep.o m68knbsd-tdep.o solib.o solib-svr4.o
  TM_FILE= tm-nbsd.h
  
  GDBSERVER_DEPFILES= low-nbsd.o
Index: config/m68k/tm-nbsd.h
===================================================================
RCS file: /cvs/src/src/gdb/config/m68k/tm-nbsd.h,v
retrieving revision 1.1
retrieving revision 1.2
diff -c -r1.1 -r1.2
*** tm-nbsd.h	1999/04/16 01:34:22	1.1
--- tm-nbsd.h	2001/01/17 23:07:15	1.2
***************
*** 1,21 ****
  /* Macro definitions for i386 running under NetBSD.
     Copyright 1994 Free Software Foundation, Inc.
  
! This file is part of GDB.
  
! This program is free software; you can redistribute it and/or modify
! it under the terms of the GNU General Public License as published by
! the Free Software Foundation; either version 2 of the License, or
! (at your option) any later version.
! 
! This program is distributed in the hope that it will be useful,
! but WITHOUT ANY WARRANTY; without even the implied warranty of
! MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
! GNU General Public License for more details.
! 
! You should have received a copy of the GNU General Public License
! along with this program; if not, write to the Free Software
! Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
  
  #ifndef TM_NBSD_H
  #define TM_NBSD_H
--- 1,22 ----
  /* Macro definitions for i386 running under NetBSD.
     Copyright 1994 Free Software Foundation, Inc.
  
!    This file is part of GDB.
  
!    This program is free software; you can redistribute it and/or modify
!    it under the terms of the GNU General Public License as published by
!    the Free Software Foundation; either version 2 of the License, or
!    (at your option) any later version.
! 
!    This program is distributed in the hope that it will be useful,
!    but WITHOUT ANY WARRANTY; without even the implied warranty of
!    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
!    GNU General Public License for more details.
! 
!    You should have received a copy of the GNU General Public License
!    along with this program; if not, write to the Free Software
!    Foundation, Inc., 59 Temple Place - Suite 330,
!    Boston, MA 02111-1307, USA.  */
  
  #ifndef TM_NBSD_H
  #define TM_NBSD_H
***************
*** 25,33 ****
  
  /* Define BPT_VECTOR if it is different than the default.
     This is the vector number used by traps to indicate a breakpoint. */
  
- #define BPT_VECTOR 0x2
- 
  /* Address of end of stack space.  */
  #define STACK_END_ADDR USRSTACK
  
--- 26,34 ----
  
  /* Define BPT_VECTOR if it is different than the default.
     This is the vector number used by traps to indicate a breakpoint. */
+ #define BPT_VECTOR		0xf
+ #define REMOTE_BPT_VECTOR	0xf
  
  /* Address of end of stack space.  */
  #define STACK_END_ADDR USRSTACK
  
***************
*** 37,41 ****
--- 38,46 ----
  
  #include "m68k/tm-m68k.h"
  #include "tm-nbsd.h"
+ 
+ extern use_struct_convention_fn m68knbsd_use_struct_convention;
+ #define USE_STRUCT_CONVENTION(gcc_p, type) \
+         m68knbsd_use_struct_convention(gcc_p, type)
  
  #endif /* TM_NBSD_H */


-- 
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Wed Jan 17 17:30:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [rfc] FREEIF -> xfree()
Date: Wed, 17 Jan 2001 17:30:00 -0000
Message-id: <3A6646C0.CDAFD1A4@cygnus.com>
X-SW-Source: 2001-01/msg00167.html
Content-length: 1862

Continuing the move to xfree().
Comments?

	Andrew
Thu Jan 18 12:25:06 2001  Andrew Cagney  <cagney@b1.cygnus.com>

	* varobj.c (FREEIF): Delete macro.
	(varobj_set_value, free_variable): Replace FREEIF with ``xfree''
 	call.

Index: varobj.c
===================================================================
RCS file: /cvs/src/src/gdb/varobj.c,v
retrieving revision 1.14
diff -p -r1.14 varobj.c
*** varobj.c	2000/12/15 01:01:51	1.14
--- varobj.c	2001/01/18 01:27:58
*************** static int rootcount = 0;	/* number of r
*** 391,401 ****
  /* Pointer to the varobj hash table (built at run time) */
  static struct vlist **varobj_table;
  
- #if defined(FREEIF)
- #undef FREEIF
- #endif
- #define FREEIF(x) if (x != NULL) free((char *) (x))
- 
  /* Is the variable X one of our "fake" children? */
  #define CPLUS_FAKE_CHILD(x) \
  ((x) != NULL && (x)->type == NULL && (x)->value == NULL)
--- 391,396 ----
*************** varobj_set_value (struct varobj *var, ch
*** 788,794 ****
        if (!gdb_evaluate_expression (exp, &value))
  	{
  	  /* We cannot proceed without a valid expression. */
! 	  FREEIF (exp);
  	  return 0;
  	}
  
--- 783,789 ----
        if (!gdb_evaluate_expression (exp, &value))
  	{
  	  /* We cannot proceed without a valid expression. */
! 	  xfree (exp);
  	  return 0;
  	}
  
*************** free_variable (struct varobj *var)
*** 1353,1364 ****
    if (var->root->rootvar == var)
      {
        free_current_contents ((char **) &var->root->exp);
!       FREEIF (var->root);
      }
  
!   FREEIF (var->name);
!   FREEIF (var->obj_name);
!   FREEIF (var);
  }
  
  static void
--- 1348,1359 ----
    if (var->root->rootvar == var)
      {
        free_current_contents ((char **) &var->root->exp);
!       xfree (var->root);
      }
  
!   xfree (var->name);
!   xfree (var->obj_name);
!   xfree (var);
  }
  
  static void
From ac131313@cygnus.com Wed Jan 17 17:58:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [rfc] Replace STRCMP() with strcmp()
Date: Wed, 17 Jan 2001 17:58:00 -0000
Message-id: <3A664D3D.62952710@cygnus.com>
X-SW-Source: 2001-01/msg00168.html
Content-length: 7933

Comments?

Unlike STREQ() and STREQN(), this is one is a text substitution so
should be ok :-)

	Andrew
Thu Jan 18 12:48:04 2001  Andrew Cagney  <cagney@b1.cygnus.com>

	* defs.h (STRCMP): Delete macro.

	* objfiles.c (objfile_relocate): Replace STRCMP with call to
 	strcmp.
	* symtab.c (lookup_partial_symbol, lookup_block_symbol): Ditto.
	* symfile.c (compare_symbols):  Ditto.
	* standalone.c (open):  Ditto.
	* remote-es.c (verify_break):  Ditto.
	* cli/cli-decode.c (add_cmd, add_show_from_set): Ditto.

	* symfile.c (compare_psymbols): Delete comment refering to STRCMP.

Index: defs.h
===================================================================
RCS file: /cvs/src/src/gdb/defs.h,v
retrieving revision 1.33
diff -p -r1.33 defs.h
*** defs.h	2000/12/15 01:01:46	1.33
--- defs.h	2001/01/18 01:54:18
*************** typedef bfd_vma CORE_ADDR;
*** 148,154 ****
     issue is found that we spend the effort on algorithmic
     optimizations than micro-optimizing.'' J.T. */
  
- #define STRCMP(a,b) (*(a) == *(b) ? strcmp ((a), (b)) : (int)*(a) - (int)*(b))
  #define STREQ(a,b) (*(a) == *(b) ? !strcmp ((a), (b)) : 0)
  #define STREQN(a,b,c) (*(a) == *(b) ? !strncmp ((a), (b), (c)) : 0)
  
--- 148,153 ----
Index: objfiles.c
===================================================================
RCS file: /cvs/src/src/gdb/objfiles.c,v
retrieving revision 1.12
diff -p -r1.12 objfiles.c
*** objfiles.c	2000/12/15 01:01:48	1.12
--- objfiles.c	2001/01/18 01:54:24
*************** objfile_relocate (struct objfile *objfil
*** 584,590 ****
  
  	      else if (SYMBOL_CLASS (sym) == LOC_CONST
  		       && SYMBOL_NAMESPACE (sym) == LABEL_NAMESPACE
! 		   && STRCMP (SYMBOL_NAME (sym), MIPS_EFI_SYMBOL_NAME) == 0)
  		ecoff_relocate_efi (sym, ANOFFSET (delta,
  						   s->block_line_section));
  #endif
--- 584,590 ----
  
  	      else if (SYMBOL_CLASS (sym) == LOC_CONST
  		       && SYMBOL_NAMESPACE (sym) == LABEL_NAMESPACE
! 		       && strcmp (SYMBOL_NAME (sym), MIPS_EFI_SYMBOL_NAME) == 0)
  		ecoff_relocate_efi (sym, ANOFFSET (delta,
  						   s->block_line_section));
  #endif
Index: remote-es.c
===================================================================
RCS file: /cvs/src/src/gdb/remote-es.c,v
retrieving revision 1.7
diff -p -r1.7 remote-es.c
*** remote-es.c	2000/12/15 01:01:48	1.7
--- remote-es.c	2001/01/18 01:54:26
*************** verify_break (int vec)
*** 1151,1157 ****
  	{
  	  memory_error (status, memaddress);
  	}
!       return (STRCMP (instr, buf));
      }
    return (-1);
  }
--- 1151,1157 ----
  	{
  	  memory_error (status, memaddress);
  	}
!       return (strcmp (instr, buf));
      }
    return (-1);
  }
Index: standalone.c
===================================================================
RCS file: /cvs/src/src/gdb/standalone.c,v
retrieving revision 1.3
diff -p -r1.3 standalone.c
*** standalone.c	2000/07/30 01:48:27	1.3
--- standalone.c	2001/01/18 01:54:29
*************** open (char *filename, int modes)
*** 145,151 ****
  
    for (next = files_start; *(int *) next; next += *(int *) next)
      {
!       if (!STRCMP (next + 4, filename))
  	{
  	  sourcebeg = next + 4 + strlen (next + 4) + 1;
  	  sourcebeg = (char *) (((int) sourcebeg + 3) & (-4));
--- 145,151 ----
  
    for (next = files_start; *(int *) next; next += *(int *) next)
      {
!       if (!strcmp (next + 4, filename))
  	{
  	  sourcebeg = next + 4 + strlen (next + 4) + 1;
  	  sourcebeg = (char *) (((int) sourcebeg + 3) & (-4));
Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.22
diff -p -r1.22 symfile.c
*** symfile.c	2000/12/15 01:01:50	1.22
--- symfile.c	2001/01/18 01:54:36
*************** compare_symbols (const PTR s1p, const PT
*** 213,219 ****
  
    s1 = (struct symbol **) s1p;
    s2 = (struct symbol **) s2p;
!   return (STRCMP (SYMBOL_SOURCE_NAME (*s1), SYMBOL_SOURCE_NAME (*s2)));
  }
  
  /*
--- 213,219 ----
  
    s1 = (struct symbol **) s1p;
    s2 = (struct symbol **) s2p;
!   return (strcmp (SYMBOL_SOURCE_NAME (*s1), SYMBOL_SOURCE_NAME (*s2)));
  }
  
  /*
*************** compare_psymbols (const PTR s1p, const P
*** 260,277 ****
      }
    else
      {
-       /* Note: I replaced the STRCMP line (commented out below)
-        * with a simpler "strcmp()" which compares the 2 strings
-        * from the beginning. (STRCMP is a macro which first compares
-        * the initial characters, then falls back on strcmp).
-        * The reason is that the STRCMP line was tickling a C compiler
-        * bug on HP-UX 10.30, which is avoided with the simpler
-        * code. The performance gain from the more complicated code
-        * is negligible, given that we have already checked the
-        * initial 2 characters above. I reported the compiler bug,
-        * and once it is fixed the original line can be put back. RT
-        */
-       /* return ( STRCMP (st1 + 2, st2 + 2)); */
        return (strcmp (st1, st2));
      }
  }
--- 260,265 ----
Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.25
diff -p -r1.25 symtab.c
*** symtab.c	2000/12/15 01:01:50	1.25
--- symtab.c	2001/01/18 01:54:42
*************** lookup_partial_symbol (struct partial_sy
*** 1004,1010 ****
  	    {
  	      do_linear_search = 1;
  	    }
! 	  if (STRCMP (SYMBOL_SOURCE_NAME (*center), name) >= 0)
  	    {
  	      top = center;
  	    }
--- 1004,1010 ----
  	    {
  	      do_linear_search = 1;
  	    }
! 	  if (strcmp (SYMBOL_SOURCE_NAME (*center), name) >= 0)
  	    {
  	      top = center;
  	    }
*************** lookup_block_symbol (register const stru
*** 1237,1243 ****
  	    {
  	      top = inc;
  	    }
! 	  else if (STRCMP (SYMBOL_SOURCE_NAME (sym), name) < 0)
  	    {
  	      bot = inc;
  	    }
--- 1237,1243 ----
  	    {
  	      top = inc;
  	    }
! 	  else if (strcmp (SYMBOL_SOURCE_NAME (sym), name) < 0)
  	    {
  	      bot = inc;
  	    }
Index: cli/cli-decode.c
===================================================================
RCS file: /cvs/src/src/gdb/cli/cli-decode.c,v
retrieving revision 1.5
diff -p -r1.5 cli-decode.c
*** cli-decode.c	2000/12/15 01:01:51	1.5
--- cli-decode.c	2001/01/18 01:54:47
*************** add_cmd (char *name, enum command_class 
*** 67,73 ****
  
    delete_cmd (name, list);
  
!   if (*list == NULL || STRCMP ((*list)->name, name) >= 0)
      {
        c->next = *list;
        *list = c;
--- 67,73 ----
  
    delete_cmd (name, list);
  
!   if (*list == NULL || strcmp ((*list)->name, name) >= 0)
      {
        c->next = *list;
        *list = c;
*************** add_cmd (char *name, enum command_class 
*** 75,81 ****
    else
      {
        p = *list;
!       while (p->next && STRCMP (p->next->name, name) <= 0)
  	{
  	  p = p->next;
  	}
--- 75,81 ----
    else
      {
        p = *list;
!       while (p->next && strcmp (p->next->name, name) <= 0)
  	{
  	  p = p->next;
  	}
*************** add_show_from_set (struct cmd_list_eleme
*** 312,318 ****
    else
      fprintf_unfiltered (gdb_stderr, "GDB internal error: Bad docstring for set command\n");
  
!   if (*list == NULL || STRCMP ((*list)->name, showcmd->name) >= 0)
      {
        showcmd->next = *list;
        *list = showcmd;
--- 312,318 ----
    else
      fprintf_unfiltered (gdb_stderr, "GDB internal error: Bad docstring for set command\n");
  
!   if (*list == NULL || strcmp ((*list)->name, showcmd->name) >= 0)
      {
        showcmd->next = *list;
        *list = showcmd;
*************** add_show_from_set (struct cmd_list_eleme
*** 320,326 ****
    else
      {
        p = *list;
!       while (p->next && STRCMP (p->next->name, showcmd->name) <= 0)
  	{
  	  p = p->next;
  	}
--- 320,326 ----
    else
      {
        p = *list;
!       while (p->next && strcmp (p->next->name, showcmd->name) <= 0)
  	{
  	  p = p->next;
  	}
From ac131313@cygnus.com Wed Jan 17 18:47:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [rfc] Replace strsave() with xstrdup()
Date: Wed, 17 Jan 2001 18:47:00 -0000
Message-id: <3A6658B9.3B5FD07F@cygnus.com>
X-SW-Source: 2001-01/msg00169.html
Content-length: 13286

Any comments?

	Andrew
Thu Jan 18 13:22:51 2001  Andrew Cagney  <cagney@b1.cygnus.com>

	* defs.h (strsave): Delete declaration.
	* utils.c (strsave): Delete definition.

	* mac-xdep.c (tilde_expand): Replace strsave with xstrdup.
	* sparcl-tdep.c (sparclite_open): Ditto.
	* mips-tdep.c (mips_set_processor_type_command):  Ditto.
	(_initialize_mips_tdep):  Ditto.
	* solib.c (solib_open):  Ditto.
	* symfile.c (add_filename_language):  Ditto.
	(set_ext_lang_command):  Ditto.
	* source.c (init_source_path):  Ditto.
	(mod_path):  Ditto.
	* sh3-rom.c (sh3_open):  Ditto.
	(sh3e_open):  Ditto.
	* serial.c (serial_open):  Ditto.
	* remote-mips.c (common_open):  Ditto.
	* monitor.c (monitor_open):  Ditto.
	* m32r-rom.c (m32r_upload_command):  Ditto.
	* infcmd.c (path_command):  Ditto.
	* f-exp.y (parse_number):  Ditto.
	* breakpoint.c (create_longjmp_breakpoint):  Ditto.
	(create_thread_event_breakpoint):  Ditto.
	* arc-tdep.c (arc_set_cpu_type_command):  Ditto.
	(_initialize_arc_tdep):  Ditto.

Index: arc-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/arc-tdep.c,v
retrieving revision 1.3
diff -u -r1.3 arc-tdep.c
--- arc-tdep.c	2000/07/30 01:48:24	1.3
+++ arc-tdep.c	2001/01/18 02:33:54
@@ -639,7 +639,7 @@
 	printf_unfiltered ("%s\n", arc_cpu_type_table[i].name);
 
       /* Restore the value.  */
-      tmp_arc_cpu_type = strsave (arc_cpu_type);
+      tmp_arc_cpu_type = xstrdup (arc_cpu_type);
 
       return;
     }
@@ -648,7 +648,7 @@
     {
       error ("Unknown cpu type `%s'.", tmp_arc_cpu_type);
       /* Restore its value.  */
-      tmp_arc_cpu_type = strsave (arc_cpu_type);
+      tmp_arc_cpu_type = xstrdup (arc_cpu_type);
     }
 }
 
@@ -698,9 +698,9 @@
   c = add_show_from_set (c, &showlist);
   c->function.cfunc = arc_show_cpu_type_command;
 
-  /* We have to use strsave here because the `set' command frees it before
-     setting a new value.  */
-  tmp_arc_cpu_type = strsave (DEFAULT_ARC_CPU_TYPE);
+  /* We have to use xstrdup() here because the `set' command frees it
+     before setting a new value.  */
+  tmp_arc_cpu_type = xstrdup (DEFAULT_ARC_CPU_TYPE);
   arc_set_cpu_type (tmp_arc_cpu_type);
 
   c = add_set_cmd ("displaypipeline", class_support, var_zinteger,
Index: breakpoint.c
===================================================================
RCS file: /cvs/src/src/gdb/breakpoint.c,v
retrieving revision 1.22
diff -u -r1.22 breakpoint.c
--- breakpoint.c	2000/12/15 01:01:45	1.22
+++ breakpoint.c	2001/01/18 02:35:10
@@ -3871,7 +3871,7 @@
   b->enable = disabled;
   b->silent = 1;
   if (func_name)
-    b->addr_string = strsave (func_name);
+    b->addr_string = xstrdup (func_name);
   b->number = internal_breakpoint_number--;
 }
 
@@ -3928,7 +3928,7 @@
   b->enable = enabled;
   /* addr_string has to be used or breakpoint_re_set will delete me.  */
   sprintf (addr_string, "*0x%s", paddr (b->address));
-  b->addr_string = strsave (addr_string);
+  b->addr_string = xstrdup (addr_string);
 
   return b;
 }
Index: defs.h
===================================================================
RCS file: /cvs/src/src/gdb/defs.h,v
retrieving revision 1.33
diff -u -r1.33 defs.h
--- defs.h	2000/12/15 01:01:46	1.33
+++ defs.h	2001/01/18 02:35:20
@@ -823,8 +823,6 @@
 
 extern char *msavestring (void *, const char *, int);
 
-extern char *strsave (const char *);
-
 extern char *mstrsave (void *, const char *);
 
 /* FIXME; was long, but this causes compile errors in msvc if already
Index: f-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/f-exp.y,v
retrieving revision 1.2
diff -u -r1.2 f-exp.y
--- f-exp.y	2000/05/28 01:12:27	1.2
+++ f-exp.y	2001/01/18 02:35:25
@@ -653,7 +653,7 @@
       /* [dD] is not understood as an exponent by atof, change it to 'e'.  */
       char *tmp, *tmp2;
 
-      tmp = strsave (p);
+      tmp = xstrdup (p);
       for (tmp2 = tmp; *tmp2; ++tmp2)
 	if (*tmp2 == 'd' || *tmp2 == 'D')
 	  *tmp2 = 'e';
Index: infcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/infcmd.c,v
retrieving revision 1.15
diff -u -r1.15 infcmd.c
--- infcmd.c	2001/01/12 09:45:57	1.15
+++ infcmd.c	2001/01/18 02:35:43
@@ -1420,7 +1420,7 @@
   /* Can be null if path is not set */
   if (!env)
     env = "";
-  exec_path = strsave (env);
+  exec_path = xstrdup (env);
   mod_path (dirname, &exec_path);
   set_in_environ (inferior_environ, path_var_name, exec_path);
   xfree (exec_path);
Index: m32r-rom.c
===================================================================
RCS file: /cvs/src/src/gdb/m32r-rom.c,v
retrieving revision 1.4
diff -u -r1.4 m32r-rom.c
--- m32r-rom.c	2000/12/02 13:43:26	1.4
+++ m32r-rom.c	2001/01/18 02:35:43
@@ -480,7 +480,7 @@
 	error ("Please use 'set board-address' to set the M32R-EVA board's IP address.");
       if (strchr (myIPaddress, '('))
 	*(strchr (myIPaddress, '(')) = '\0';	/* delete trailing junk */
-      board_addr = strsave (myIPaddress);
+      board_addr = xstrdup (myIPaddress);
     }
   if (server_addr == 0)
     {
@@ -508,7 +508,7 @@
   if (args[0] != '/' && download_path == 0)
     {
       if (current_directory)
-	download_path = strsave (current_directory);
+	download_path = xstrdup (current_directory);
       else
 	error ("Need to know default download path (use 'set download-path')");
     }
Index: mac-xdep.c
===================================================================
RCS file: /cvs/src/src/gdb/mac-xdep.c,v
retrieving revision 1.2
diff -u -r1.2 mac-xdep.c
--- mac-xdep.c	2000/07/30 01:48:26	1.2
+++ mac-xdep.c	2001/01/18 02:35:43
@@ -926,7 +926,7 @@
 char *
 tilde_expand (char *str)
 {
-  return strsave (str);
+  return xstrdup (str);
 }
 
 /* Modified versions of standard I/O. */
Index: mips-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/mips-tdep.c,v
retrieving revision 1.38
diff -u -r1.38 mips-tdep.c
--- mips-tdep.c	2001/01/04 23:22:45	1.38
+++ mips-tdep.c	2001/01/18 02:36:20
@@ -3331,7 +3331,7 @@
 	printf_unfiltered ("%s\n", mips_processor_type_table[i].name);
 
       /* Restore the value.  */
-      tmp_mips_processor_type = strsave (mips_processor_type);
+      tmp_mips_processor_type = xstrdup (mips_processor_type);
 
       return;
     }
@@ -3340,7 +3340,7 @@
     {
       error ("Unknown processor type `%s'.", tmp_mips_processor_type);
       /* Restore its value.  */
-      tmp_mips_processor_type = strsave (mips_processor_type);
+      tmp_mips_processor_type = xstrdup (mips_processor_type);
     }
 }
 
@@ -4610,8 +4610,8 @@
   c = add_show_from_set (c, &showlist);
   c->function.cfunc = mips_show_processor_type_command;
 
-  tmp_mips_processor_type = strsave (DEFAULT_MIPS_TYPE);
-  mips_set_processor_type_command (strsave (DEFAULT_MIPS_TYPE), 0);
+  tmp_mips_processor_type = xstrdup (DEFAULT_MIPS_TYPE);
+  mips_set_processor_type_command (xstrdup (DEFAULT_MIPS_TYPE), 0);
 #endif
 
   /* We really would like to have both "0" and "unlimited" work, but
Index: monitor.c
===================================================================
RCS file: /cvs/src/src/gdb/monitor.c,v
retrieving revision 1.15
diff -u -r1.15 monitor.c
--- monitor.c	2000/12/15 01:01:48	1.15
+++ monitor.c	2001/01/18 02:36:35
@@ -753,7 +753,7 @@
 
   if (dev_name)
     xfree (dev_name);
-  dev_name = strsave (args);
+  dev_name = xstrdup (args);
 
   monitor_desc = SERIAL_OPEN (dev_name);
 
Index: remote-mips.c
===================================================================
RCS file: /cvs/src/src/gdb/remote-mips.c,v
retrieving revision 1.11
diff -u -r1.11 remote-mips.c
--- remote-mips.c	2000/12/15 01:01:48	1.11
+++ remote-mips.c	2001/01/18 02:37:29
@@ -1528,7 +1528,7 @@
     nomem (0);
   make_cleanup_freeargv (argv);
 
-  serial_port_name = strsave (argv[0]);
+  serial_port_name = xstrdup (argv[0]);
   if (argv[1])			/* remote TFTP name specified? */
     {
       remote_name = argv[1];
@@ -1584,8 +1584,8 @@
 	      local_name++;	/* skip over the colon */
 	  if (local_name == NULL)
 	    local_name = remote_name;	/* local name same as remote name */
-	  tftp_name = strsave (remote_name);
-	  tftp_localname = strsave (local_name);
+	  tftp_name = xstrdup (remote_name);
+	  tftp_localname = xstrdup (local_name);
 	  tftp_in_use = 1;
 	}
     }
@@ -1595,7 +1595,7 @@
 
   /* Reset the expected monitor prompt if it's never been set before.  */
   if (mips_monitor_prompt == NULL)
-    mips_monitor_prompt = strsave (new_monitor_prompt);
+    mips_monitor_prompt = xstrdup (new_monitor_prompt);
   mips_monitor = new_monitor;
 
   mips_initialize ();
@@ -1611,7 +1611,7 @@
   /* Try to figure out the processor model if possible.  */
   ptype = mips_read_processor_type ();
   if (ptype)
-    mips_set_processor_type_command (strsave (ptype), 0);
+    mips_set_processor_type_command (xstrdup (ptype), 0);
 
 /* This is really the job of start_remote however, that makes an assumption
    that the target is about to print out a status message of some sort.  That
Index: serial.c
===================================================================
RCS file: /cvs/src/src/gdb/serial.c,v
retrieving revision 1.6
diff -u -r1.6 serial.c
--- serial.c	2000/12/15 12:04:03	1.6
+++ serial.c	2001/01/18 02:37:36
@@ -213,7 +213,7 @@
       return NULL;
     }
 
-  scb->name = strsave (name);
+  scb->name = xstrdup (name);
   scb->next = scb_base;
   scb->refcnt = 1;
   scb->debug_p = 0;
Index: sh3-rom.c
===================================================================
RCS file: /cvs/src/src/gdb/sh3-rom.c,v
retrieving revision 1.5
diff -u -r1.5 sh3-rom.c
--- sh3-rom.c	2000/07/30 01:48:27	1.5
+++ sh3-rom.c	2001/01/18 02:37:36
@@ -249,7 +249,7 @@
 
   if (args)
     {
-      char *cursor = serial_port_name = strsave (args);
+      char *cursor = serial_port_name = xstrdup (args);
 
       while (*cursor && *cursor != ' ')
 	cursor++;
@@ -289,7 +289,7 @@
 
   if (args)
     {
-      char *cursor = serial_port_name = strsave (args);
+      char *cursor = serial_port_name = xstrdup (args);
 
       while (*cursor && *cursor != ' ')
 	cursor++;
Index: solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.31
diff -u -r1.31 solib.c
--- solib.c	2000/12/23 00:27:20	1.31
+++ solib.c	2001/01/18 02:37:44
@@ -143,7 +143,7 @@
   /* Done.  If not found, tough luck.  Return found_file and 
      (optionally) found_pathname.  */
   if (found_pathname != NULL && temp_pathname != NULL)
-    *found_pathname = strsave (temp_pathname);
+    *found_pathname = xstrdup (temp_pathname);
   return found_file;
 }
 
Index: source.c
===================================================================
RCS file: /cvs/src/src/gdb/source.c,v
retrieving revision 1.7
diff -u -r1.7 source.c
--- source.c	2001/01/16 17:36:44	1.7
+++ source.c	2001/01/18 02:37:58
@@ -255,7 +255,7 @@
   char buf[20];
 
   sprintf (buf, "$cdir%c$cwd", DIRNAME_SEPARATOR);
-  source_path = strsave (buf);
+  source_path = xstrdup (buf);
   forget_cached_source_info ();
 }
 
@@ -295,7 +295,7 @@
   if (dirname == 0)
     return;
 
-  dirname = strsave (dirname);
+  dirname = xstrdup (dirname);
   make_cleanup (xfree, dirname);
 
   do
Index: sparcl-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/sparcl-tdep.c,v
retrieving revision 1.8
diff -u -r1.8 sparcl-tdep.c
--- sparcl-tdep.c	2000/12/15 01:01:49	1.8
+++ sparcl-tdep.c	2001/01/18 02:37:58
@@ -413,7 +413,7 @@
   if (remote_target_name)
     xfree (remote_target_name);
 
-  remote_target_name = strsave (name);
+  remote_target_name = xstrdup (name);
 
   /* We need a 'serial' or 'udp' keyword to disambiguate host:port, which can
      mean either a serial port on a terminal server, or the IP address of a
Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.22
diff -u -r1.22 symfile.c
--- symfile.c	2000/12/15 01:01:50	1.22
+++ symfile.c	2001/01/18 02:38:20
@@ -1783,7 +1783,7 @@
 					 fl_table_size);
     }
 
-  filename_language_table[fl_table_next].ext = strsave (ext);
+  filename_language_table[fl_table_next].ext = xstrdup (ext);
   filename_language_table[fl_table_next].lang = lang;
   fl_table_next++;
 }
@@ -1842,7 +1842,7 @@
       /*          ext_args, language_str (lang));           */
 
       xfree (filename_language_table[i].ext);
-      filename_language_table[i].ext = strsave (ext_args);
+      filename_language_table[i].ext = xstrdup (ext_args);
       filename_language_table[i].lang = lang;
     }
 }
Index: utils.c
===================================================================
RCS file: /cvs/src/src/gdb/utils.c,v
retrieving revision 1.25
diff -u -r1.25 utils.c
--- utils.c	2000/12/15 01:01:50	1.25
+++ utils.c	2001/01/18 02:38:31
@@ -1162,15 +1162,6 @@
   return p;
 }
 
-/* The "const" is so it compiles under DGUX (which prototypes strsave
-   in <string.h>.  FIXME: This should be named "xstrsave", shouldn't it?
-   Doesn't real strsave return NULL if out of memory?  */
-char *
-strsave (const char *ptr)
-{
-  return savestring (ptr, strlen (ptr));
-}
-
 char *
 mstrsave (void *md, const char *ptr)
 {
From ac131313@cygnus.com Wed Jan 17 22:46:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [Fwd: [rfc] Remove 5.0 obsolete code]
Date: Wed, 17 Jan 2001 22:46:00 -0000
Message-id: <3A6690B8.F1C1F0D@cygnus.com>
X-SW-Source: 2001-01/msg00170.html
Content-length: 8520

(Sorry, wrong mailing list.)


To : GDB Discussion <gdb at sourceware dot cygnus dot com>
Subject : [rfc] Remove 5.0 obsolete code
From : Andrew Cagney <ac131313 at cygnus dot com>
Date : Thu, 18 Jan 2001 15:52:12 +1100

Hello,

This follows up a discussion on the gdb@ mailing list.  It removes the
obsolete targets.  I would draw your attention to the news file where it
will now read:

* OBSOLETE configurations
....
Configurations that have been declared obsolete in this release have
been commented out.  Unless there is activity to revive these
configurations, the next release of GDB will have their sources
permanently REMOVED.

In GDB 5.0 this note read:

Configurations that have been declared obsolete will be commented out,
but the code will be left in place.  If there is no activity to revive
these configurations before the next release of GDB, the sources will
be permanently REMOVED.

The old paragraph could give the impression that the removal would only
occure just before the next GDB release.  Given that everything is in
CVS this is no longer needed.

	Andrew
Thu Jan 18 14:03:13 2001  Andrew Cagney  <cagney@b1.cygnus.com>

	* configure.tgt: Remove references to convex, pyramid, altos and
 	tahoe.
 	* configure.host: Ditto.
	* MAINTAINERS: Ditto.
	* NEWS: Update.

	* tahoe-tdep.c: Delete obsolete file.
	* pyr-xdep.c: Ditto.
	* pyr-tdep.c: Ditto.
	* convex-tdep.c: Ditto.
	* convex-xdep.c: Ditto.
	* config/tahoe/xm-tahoe.h: Ditto.
	* config/tahoe/tm-tahoe.h: Ditto.
	* config/tahoe/tahoe.mt: Ditto.
	* config/tahoe/tahoe.mh: Ditto.
	* config/pyr/xm-pyr.h: Ditto.
	* config/pyr/tm-pyr.h: Ditto.
	* config/pyr/pyramid.mt: Ditto.
	* config/pyr/pyramid.mh: Ditto.
	* config/m68k/xm-altos.h: Ditto.
	* config/m68k/tm-altos.h: Ditto.
	* config/m68k/altos.mt: Ditto.
	* config/m68k/altos.mh: Ditto.
	* config/convex/xm-convex.h: Ditto.
	* config/convex/tm-convex.h: Ditto.
	* config/convex/convex.mt: Ditto.
	* config/convex/convex.mh: Ditto.
	* config/convex/Convex.notes: Ditto.
	* config/arm/xm-arm.h: Ditto.
	* config/arm/nm-arm.h: Ditto.
	* config/arm/arm.mt: Ditto.
	* config/arm/arm.mh: Ditto.
	* arm-convert.s: Ditto.
	* arm-xdep.c: Ditto.
	* altos-xdep.c: Ditto.

Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.62
diff -p -r1.62 MAINTAINERS
*** MAINTAINERS	2001/01/16 22:45:48	1.62
--- MAINTAINERS	2001/01/18 03:36:42
*************** maintainer works with the native maintai
*** 42,49 ****
  			Jim Ingham		jingham@apple.com
  			Scott Bambrough		scottb@netwinder.org
  
- 	convex		OBSOLETE
- 
  	d10v		Andrew Cagney		cagney@cygnus.com
  
  	d30v		David Taylor		taylor@cygnus.com
--- 42,47 ----
*************** maintainer works with the native maintai
*** 80,87 ****
  	powerpc		Kevin Buettner		kevinb@cygnus.com
  			Nick Duffek		nsd@cygnus.com
  
- 	pyramid		OBSOLETE
- 
  	romp		maintenance only (?)
  
  	rs6000		(see rs6000 native and ppc target)
--- 78,83 ----
*************** maintainer works with the native maintai
*** 89,96 ****
  	sh		Elena Zannoni		ezannoni@cygnus.com
  
  	sparc		David Taylor		taylor@cygnus.com
- 
- 	tahoe		OBSOLETE
  
  	tic80		maintenance only (tic80-coff)
  	v850		maintenance only (v850-elf)
--- 85,90 ----
Index: NEWS
===================================================================
RCS file: /cvs/src/src/gdb/NEWS,v
retrieving revision 1.11
diff -p -r1.11 NEWS
*** NEWS	2000/10/24 05:22:11	1.11
--- NEWS	2001/01/18 03:37:26
*************** x86 FreeBSD 3.x and 4.x				i[3456]86*-fr
*** 14,20 ****
  
  x86 FreeBSD before 2.2				i[3456]86*-freebsd{1,2.[01]}*, 
  
! * Deleted configurations
  
  * Other news:
  
--- 14,31 ----
  
  x86 FreeBSD before 2.2				i[3456]86*-freebsd{1,2.[01]}*, 
  
! Configurations that have been declared obsolete in this release have
! been commented out.  Unless there is activity to revive these
! configurations, the next release of GDB will have their sources
! permanently REMOVED.
! 
! * REMOVED configurations
! 
! Altos 3068					m68*-altos-*
! Convex						c1-*-*, c2-*-*
! Pyramid						pyramid-*-*
! ARM RISCix					arm-*-* (as host)
! Tahoe						tahoe-*-*
  
  * Other news:
  
Index: configure.host
===================================================================
RCS file: /cvs/src/src/gdb/configure.host,v
retrieving revision 1.10
diff -p -r1.10 configure.host
*** configure.host	2000/11/26 20:04:41	1.10
--- configure.host	2001/01/18 03:37:26
*************** case "${host_cpu}" in
*** 12,23 ****
  
  alpha*)			gdb_host_cpu=alpha ;;
  arm*)			gdb_host_cpu=arm ;;
- # OBSOLETE c[12])		gdb_host_cpu=convex ;;
  hppa*)			gdb_host_cpu=pa ;;
  i[3456]86*)		gdb_host_cpu=i386 ;;
  m68*)			gdb_host_cpu=m68k ;;
  m88*)			gdb_host_cpu=m88k ;;
- # OBSOLETE pyramid)		gdb_host_cpu=pyr ;;
  powerpc*)		gdb_host_cpu=powerpc ;;
  sparc64)		gdb_host_cpu=sparc ;;
  *)			gdb_host_cpu=$host_cpu ;;
--- 12,21 ----
*************** alpha*-*-freebsd*)	gdb_host=fbsd ;;
*** 39,46 ****
  arm*-*-linux*)		gdb_host=linux ;;
  arm*-*-*)		gdb_host=arm ;;
  
- # OBSOLETE c[12]-*-*)		gdb_host=convex ;;
- 
  hppa*-*-bsd*)		gdb_host=hppabsd ;;
  hppa*-*-hiux*)		gdb_host=hppahpux ;;
  hppa*-*-hpux10.20)	gdb_host=hpux1020 ;;
--- 37,42 ----
*************** m680[01]0-sun-sunos3*)	gdb_host=sun2os3 
*** 90,96 ****
  m680[01]0-sun-sunos4*)	gdb_host=sun2os4 ;;
  m68030-sony-*)		gdb_host=news1000 ;;
  
- # OBSOLETE m68*-altos-*)	gdb_host=altos ;;
  m68*-apollo*-sysv*)	gdb_host=apollo68v ;;
  m68*-apollo*-bsd*)	gdb_host=apollo68b ;;
  m68*-att-*)		gdb_host=3b1 ;;
--- 86,91 ----
*************** powerpcle-*-solaris*)	gdb_host=solaris ;
*** 140,149 ****
  powerpc-*-linux*)	gdb_host=linux ;;
  powerpc-*-netbsd*)	gdb_host=nbsd ;;
  
- # OBSOLETE pn-*-*)		gdb_host=pn ;;
- 
- # OBSOLETE pyramid-*-*)		gdb_host=pyramid ;;
- 
  romp-*-*)		gdb_host=rtbsd ;;
  
  rs6000-*-lynxos*)	gdb_host=rs6000lynx ;;
--- 135,140 ----
*************** sparc64-*-*)		gdb_host=sun4sol2 ;;
*** 163,170 ****
  
  strongarm-*-*)		gdb_host=arm ;;
  xscale-*-*)		gdb_host=arm ;;
- 
- # OBSOLETE tahoe-*-*)		gdb_host=tahoe ;;
  
  vax-*-bsd*)		gdb_host=vaxbsd ;;
  vax-*-ultrix2*)		gdb_host=vaxult2 ;;
--- 154,159 ----
Index: configure.tgt
===================================================================
RCS file: /cvs/src/src/gdb/configure.tgt,v
retrieving revision 1.16
diff -p -r1.16 configure.tgt
*** configure.tgt	2000/12/14 20:15:45	1.16
--- configure.tgt	2001/01/18 03:37:26
*************** case "${target_cpu}" in
*** 14,20 ****
  
  alpha*)			gdb_target_cpu=alpha ;;
  arm*)			gdb_target_cpu=arm ;;
- # OBSOLETE c[12])		gdb_target_cpu=convex ;;
  hppa*)			gdb_target_cpu=pa ;;
  i[3456]86*)		gdb_target_cpu=i386 ;;
  m68hc11*|m6811*)	gdb_target_cpu=m68hc11 ;;
--- 14,19 ----
*************** m68*)			gdb_target_cpu=m68k ;;
*** 22,28 ****
  m88*)			gdb_target_cpu=m88k ;;
  mips*)			gdb_target_cpu=mips ;;
  powerpc*)		gdb_target_cpu=powerpc ;;
- # OBSOLETE pyramid)		gdb_target_cpu=pyr ;;
  sparc*)			gdb_target_cpu=sparc ;;
  thumb*)			gdb_target_cpu=arm ;;
  strongarm*)		gdb_target_cpu=arm ;;
--- 21,26 ----
*************** arm*-*-* | thumb*-*-* | strongarm*-*-*)
*** 63,70 ****
  xscale-*-*)		gdb_target=embed
                          configdirs="$configdirs rdi-share"
                          ;;
- # OBSOLETE c1-*-*)		gdb_target=convex ;;
- # OBSOLETE c2-*-*)		gdb_target=convex ;;
  
  d10v-*-*)		gdb_target=d10v ;;
  d30v-*-*)		gdb_target=d30v ;;
--- 61,66 ----
*************** m68*-apollo*-bsd*)	gdb_target=apollo68b 
*** 149,155 ****
  m68*-bull-sysv*)	gdb_target=dpx2 ;;
  m68*-hp-bsd*)		gdb_target=hp300bsd ;;
  m68*-hp-hpux*)		gdb_target=hp300hpux ;;
- # OBSOLETE m68*-altos-*)	gdb_target=altos ;;
  m68*-att-*)		gdb_target=3b1 ;;
  m68*-cisco*-*)		gdb_target=cisco ;;
  m68*-ericsson-*)	gdb_target=es1800 ;;
--- 145,150 ----
*************** powerpcle-*-eabi* | powerpcle-*-sysv* | 
*** 255,262 ****
  powerpc-*-linux*)	gdb_target=linux ;;
  powerpc-*-vxworks*)	gdb_target=vxworks ;;
  
- # OBSOLETE pyramid-*-*)		gdb_target=pyramid ;;
- 
  rs6000-*-lynxos*)	gdb_target=rs6000lynx
  		configdirs="${configdirs} gdbserver" ;;
  rs6000-*-aix4*)		gdb_target=aix4 ;;
--- 250,255 ----
*************** sparc86x-*-*)		gdb_target=sparclite ;;
*** 288,295 ****
  # deleted though presumably it should be eventually.
  #sparc64-*-solaris2*)	gdb_target=sp64sol2 ;;
  sparc64-*-*)		gdb_target=sp64 ;;
- 
- # OBSOLETE tahoe-*-*)		gdb_target=tahoe ;;
  
  tic80-*-*)		gdb_target=tic80
  			configdirs="${configdirs} gdbserver" ;;
--- 281,286 ----
From ac131313@cygnus.com Wed Jan 17 22:56:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Nick Clifton <nickc@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: Fix to build arc-tdep.c with new ARC machine numbers
Date: Wed, 17 Jan 2001 22:56:00 -0000
Message-id: <3A669318.D4BA6E4D@cygnus.com>
References: <200101112131.NAA30844@elmo.cygnus.com>
X-SW-Source: 2001-01/msg00171.html
Content-length: 2273

Nick Clifton wrote:
> 
> Hi Guys,
> 
>   The ARC port in binutils was recently changes by a submission from
>   Peter Taggert at arccores.com.  This change introduced some new
>   machine numbers for the ARC and also changed how the disassembler is
>   invoked.  The patch below makes adjustments to arc-tdep.c for both
>   of these changes.
> 
>   OK to apply ?

Approved (but with reservations).

If the ARC target is going to have a long term future then it needs to
move away from this arc_cpu_type[] table and onto multi-arch.  If there
is any intention to extend the ARC target support beyond this simple
patch then, again, it will need to first be multi-arched.

	Andrew


> Cheers
>         Nick
> 
> 2001-01-11  Nick Clifton  <nickc@redhat.com>
> 
>         * arc-tdep.c (arc_cpu_type_table): Add new arc core numbers.
>         (arc_print_insn): No bfd available, so pass NULL to
>         arc_get_disassembler.
> 
> Index: gdb/arc-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/arc-tdep.c,v
> retrieving revision 1.3
> diff -p -r1.3 arc-tdep.c
> *** arc-tdep.c  2000/07/30 01:48:24     1.3
> --- arc-tdep.c  2001/01/11 21:27:27
> *************** struct
> *** 44,56 ****
>     }
>   arc_cpu_type_table[] =
>   {
> !   {
> !     "base", bfd_mach_arc_base
> !   }
> !   ,
> !   {
> !     NULL, 0
> !   }
>   };
> 
>   /* Used by simulator.  */
> --- 44,54 ----
>     }
>   arc_cpu_type_table[] =
>   {
> !   { "arc5", bfd_mach_arc_5 },
> !   { "arc6", bfd_mach_arc_6 },
> !   { "arc7", bfd_mach_arc_7 },
> !   { "arc8", bfd_mach_arc_8 },
> !   {  NULL,  0 }
>   };
> 
>   /* Used by simulator.  */
> *************** arc_print_insn (bfd_vma vma, disassemble
> *** 618,625 ****
>       {
>         current_mach = arc_bfd_mach_type;
>         current_endian = TARGET_BYTE_ORDER;
> !       current_disasm = arc_get_disassembler (current_mach,
> !                                            current_endian == BIG_ENDIAN);
>       }
> 
>     return (*current_disasm) (vma, info);
> --- 616,622 ----
>       {
>         current_mach = arc_bfd_mach_type;
>         current_endian = TARGET_BYTE_ORDER;
> !       current_disasm = arc_get_disassembler (NULL);
>       }
> 
>     return (*current_disasm) (vma, info);
From eliz@is.elta.co.il Thu Jan 18 00:43:00 2001
From: Eli Zaretskii <eliz@is.elta.co.il>
To: Christopher Faylor <cgf@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Thu, 18 Jan 2001 00:43:00 -0000
Message-id: <Pine.SUN.3.91.1010118104033.3768K-100000@is>
References: <20010117161229.B15404@redhat.com>
X-SW-Source: 2001-01/msg00172.html
Content-length: 667

On Wed, 17 Jan 2001, Christopher Faylor wrote:

> What does everyone think about setting a "vote system" for this kind
> of contingency?

Voting doesn't sound right, if a simple majority can win.  I think if
a patch draws opposition, it should be rejected even if the opposing
parties are in the minority.

Also, it might be useful if the individual who suggests the patch
tries to play ``devil's advocate'' and describe the possible downsides
of the patch, to allow others make up their minds in a more educated
way.  The rationale for this is that, in the absence of the
responsible maintainer, we might lack insight and know-how to make
good decisions on our own.
From ac131313@cygnus.com Thu Jan 18 05:03:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [rfc] MAINTAINERS target buildable list and configure.in wind-back
Date: Thu, 18 Jan 2001 05:03:00 -0000
Message-id: <3A66E90C.3162F8B5@cygnus.com>
X-SW-Source: 2001-01/msg00173.html
Content-length: 7107

Hello,

This change does two things:

	o	For each ISA it specifies a target
		that is known to build (or failing that
		should probably build)

	o	winds back the -Werror list dropping
		-Wuninitialized.  That is a catch 22.
		Unless -Wuninitialized warnings are
		displayed no one will think of fixing
		them but if you add -Wuninit, GDB
		won't compile with -Werror :-/

It follows through an earlier and very similar patch.  The host/build
was FreeBSD 3.5.x.  From memory, the most common build problem was
attributable to <link.h> being included when it shouldn't.

thoughts?

	Andrew

PS:

awk < "${maintainers}" '
$2 ~ /^--target=.*/ {
    targets = gensub (/--target=/, "", 1, $2)
    split (targets, targ, /,/)
    for (i in targ) {
        print targ[i], $3
    }
}
' | while read target warnings
do
Thu Jan 18 12:08:57 2001  Andrew Cagney  <cagney@b1.cygnus.com>

	* configure.in (build_warnings): Disable -Wuninitialized until GDB
 	compiles with -Wuninitialized,-Werror.
	* configure: Regenerate.

	* MAINTAINERS: Add list of targets.

Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.62
diff -p -r1.62 MAINTAINERS
*** MAINTAINERS	2001/01/16 22:45:48	1.62
--- MAINTAINERS	2001/01/18 11:55:29
*************** variants.  *-tdep.c. The Target/Architec
*** 34,102 ****
  host maintainer when resolving build issues.  The Target/Architecture
  maintainer works with the native maintainer when resolving API issues.
  
! 	a29k		maintenance only (a29k-amd-udi -Werror)
! 	alpha		maintenance only (alpha-dec-osf4.0a)
! 	arc		maintenance only (arc-elf)
  
! 	arm		Fernando Nasser		fnasser@cygnus.com
  			Jim Ingham		jingham@apple.com
  			Scott Bambrough		scottb@netwinder.org
  
  	convex		OBSOLETE
  
! 	d10v		Andrew Cagney		cagney@cygnus.com
  
! 	d30v		David Taylor		taylor@cygnus.com
  
! 	djgpp		(see native and host)
  
! 	fr30		maintenance only (fr30-elf)
! 	h8300		maintenance only (h8300hms)
! 	h8500		maintenance only (h8500hms)
  
! 	i386		Mark Kettenis           kettenis@gnu.org
  
! 	i960		maintenance only (i960-coff)
  
! 	ia64		Kevin Buettner		kevinb@cygnus.com
! 	m32r		Michael Snyder		msnyder@cygnus.com
  
! 	m68hc11		Stephane Carrez		Stephane.Carrez@worldnet.fr
  
! 	m68k		maintenance only (m68k-aout, m68k-coff, m68k-elf)
! 	m88k		maintenance only (?)
! 	mcore		maintenance only (?)
  
! 	mips		Andrew Cagney		cagney@cygnus.com
  
! 	mn10200		maintenance only (mn10200-elf)
  
! 	mn10300		Andrew Cagney		cagney@cygnus.com
  
! 	ns32k		maintenance only (?)
  
! 	pa		Jeff Law		law@cygnus.com
  
! 	powerpc		Kevin Buettner		kevinb@cygnus.com
  			Nick Duffek		nsd@cygnus.com
  
  	pyramid		OBSOLETE
  
! 	romp		maintenance only (?)
  
! 	rs6000		(see rs6000 native and ppc target)
  
! 	sh		Elena Zannoni		ezannoni@cygnus.com
  
! 	sparc		David Taylor		taylor@cygnus.com
  
  	tahoe		OBSOLETE
  
! 	tic80		maintenance only (tic80-coff)
! 	v850		maintenance only (v850-elf)
! 	vax		maintenance only (vax-dec-vms5.5)
! 	w65		maintenance only (?)
! 	z8k		maintenance only (?)
  
  All maintainers can make arbitrary changes to OBSOLETE targets.
  
--- 34,146 ----
  host maintainer when resolving build issues.  The Target/Architecture
  maintainer works with the native maintainer when resolving API issues.
  
! 	a29k		--target=a29k-amd-udi -Werror
! 			Maintenance only
  
! 	alpha		--target=alpha-dec-osf4.0a -Werror
! 			Maintenance only
! 
! 	arc		--target=arc-elf ,-Werror
! 			Maintenance only
! 
! 	arm		--target=arm-coff,arm-elf,arm-pe ,-Werror
! 			Fernando Nasser		fnasser@cygnus.com
  			Jim Ingham		jingham@apple.com
  			Scott Bambrough		scottb@netwinder.org
  
  	convex		OBSOLETE
+ 
+ 	d10v		--target=d10v-elf ,-Werror
+ 			Andrew Cagney		cagney@cygnus.com
+ 
+ 	d30v		--target=d30v-elf ,-Werror
+ 			David Taylor		taylor@cygnus.com
+ 
+ 	djgpp		--target=i586-pc-msdosdjgpp ,-Werror
+ 			(See native and host)
+ 
+ 	fr30		--target=fr30-elf -Werror
+ 			Maintenance only
  
! 	h8300		--target=h8300hms -Werror
! 			Maintenance only
  
! 	h8500		--target=h8500hms -Werror
! 			Maintenance only
  
! 	i386		--target=i386-elf,i386-aout ,-Werror
! 			Mark Kettenis           kettenis@gnu.org
  
! 	i960		(--target=i960-coff broken)
! 			Maintenance only
  
! 	ia64		(--target=ia64-elf broken)
! 			Kevin Buettner		kevinb@cygnus.com
  
! 	m32r		--target=m32r-elf -Werror
! 			Michael Snyder		msnyder@cygnus.com
  
! 	m68hc11		--target=m68hc11-elf ,-Werror
! 			Stephane Carrez		Stephane.Carrez@worldnet.fr
  
! 	m68k		--target=m68k-aout,m68k-coff,m68k-elf ,-Werror
! 			Maintenance only
  
! 	m88k		(?)
! 			Maintenance only
  
! 	mcore		(--target=mcore-elf,mcore-pe broken)
! 			Maintenance only
  
! 	mips		--target=mips-elf,mips64-elf ,-Werror
! 			Andrew Cagney		cagney@cygnus.com
  
! 	mn10200		(--target=mn10200-elf broken)
! 			Maintenance only
  
! 	mn10300		(--target=mn10300-elf broken)
! 			Andrew Cagney		cagney@cygnus.com
  
! 	ns32k		(--target=ns32k-netbsd broken)
! 			Maintenance only
  
! 	pa		(--target=hppa1.1-hp-proelf broken)
! 			Jeff Law		law@cygnus.com
! 
! 	powerpc		(--target=powerpc-eabi,powerpcle-eabi broken)
! 			Kevin Buettner		kevinb@cygnus.com
  			Nick Duffek		nsd@cygnus.com
  
  	pyramid		OBSOLETE
  
! 	romp		(?)
! 			Maintenance only
  
! 	rs6000		--target=rs6000-ibm-aix3.2,rs6000-ibm-aix4.1 ,-Werror
! 			(see rs6000 native and ppc target)
  
! 	sh		(--target=sh-hms,sh-elf broken)
! 			Elena Zannoni		ezannoni@cygnus.com
  
! 	sparc		--target=sparc-elf,sparc64-elf ,-Werror
! 			David Taylor		taylor@cygnus.com
  
  	tahoe		OBSOLETE
+ 
+ 	tic80		(--target=tic80-coff broken)
+ 			Maintenance only
+ 
+ 	v850		(--target=v850-elf broken)
+ 			Maintenance only
+ 
+ 	vax		--target=vax-dec-vms5.5 ,-Werror
+ 			Maintenance only
+ 
+ 	w65		(--target=w64 broken)
+ 			Maintenance only
  
! 	z8k		(--target=z8k-coff broken)
! 			Maintenance only
  
  All maintainers can make arbitrary changes to OBSOLETE targets.
  
Index: configure.in
===================================================================
RCS file: /cvs/src/src/gdb/configure.in,v
retrieving revision 1.53
diff -p -r1.53 configure.in
*** configure.in	2000/12/21 16:16:17	1.53
--- configure.in	2001/01/18 11:55:47
*************** fi
*** 594,600 ****
  # NOTE: If you add to this list, remember to update
  # gdb/doc/gdbint.texinfo.
  build_warnings="-Wimplicit -Wreturn-type -Wcomment -Wtrigraphs \
! -Wformat -Wparentheses -Wpointer-arith -Wuninitialized"
  # Up for debate: -Wswitch -Wcomment -trigraphs -Wtrigraphs
  # -Wunused-function -Wunused-label -Wunused-variable -Wunused-value
  # -Wchar-subscripts -Wuninitialized -Wtraditional -Wshadow -Wcast-qual
--- 594,600 ----
  # NOTE: If you add to this list, remember to update
  # gdb/doc/gdbint.texinfo.
  build_warnings="-Wimplicit -Wreturn-type -Wcomment -Wtrigraphs \
! -Wformat -Wparentheses -Wpointer-arith"
  # Up for debate: -Wswitch -Wcomment -trigraphs -Wtrigraphs
  # -Wunused-function -Wunused-label -Wunused-variable -Wunused-value
  # -Wchar-subscripts -Wuninitialized -Wtraditional -Wshadow -Wcast-qual
From ac131313@cygnus.com Thu Jan 18 07:28:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Mark Salter <msalter@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Z packet change
Date: Thu, 18 Jan 2001 07:28:00 -0000
Message-id: <3A670B0F.602D7C94@cygnus.com>
References: <200010271317.e9RDHVL10194@deneb.localdomain>
X-SW-Source: 2001-01/msg00174.html
Content-length: 1727

Mark Salter wrote:
> 
> The following patch changes the Z packet support for hw breakpoints to
> match the documentation. Its not clear to me if we should do this or
> change the documentation to make make the 'len' field optional. Some
> hw lets you specify a range for hw breakpoints and although gdb doesn't
> support that right now, it may in the future.

FYI,

I've committed this patch.

	Andrew

> 2000-10-27  Mark Salter  <msalter@redhat.com>
> 
>         * remote.c (remote_remove_hw_breakpoint): Add 'len' field to Z packet.
>         (remote_insert_hw_breakpoint): Ditto.
> 
> Index: remote.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/remote.c,v
> retrieving revision 1.26
> diff -p -c -r1.26 remote.c
> *** remote.c    2000/10/23 22:49:28     1.26
> --- remote.c    2000/10/27 13:06:52
> *************** remote_insert_hw_breakpoint (CORE_ADDR a
> *** 4433,4439 ****
> 
>     addr = remote_address_masked (addr);
>     p += hexnumstr (p, (ULONGEST) addr);
> !   *p = '\0';
> 
>     putpkt (buf);
>     getpkt (buf, PBUFSIZ, 0);
> --- 4433,4439 ----
> 
>     addr = remote_address_masked (addr);
>     p += hexnumstr (p, (ULONGEST) addr);
> !   sprintf (p, ",%x", len);
> 
>     putpkt (buf);
>     getpkt (buf, PBUFSIZ, 0);
> *************** remote_remove_hw_breakpoint (CORE_ADDR a
> *** 4469,4475 ****
> 
>     addr = remote_address_masked (addr);
>     p += hexnumstr (p, (ULONGEST) addr);
> !   *p = '\0';
> 
>     putpkt(buf);
>     getpkt (buf, PBUFSIZ, 0);
> --- 4469,4475 ----
> 
>     addr = remote_address_masked (addr);
>     p += hexnumstr (p, (ULONGEST) addr);
> !   sprintf (p, ",%x", len);
> 
>     putpkt(buf);
>     getpkt (buf, PBUFSIZ, 0);
From fnasser@cygnus.com Thu Jan 18 07:52:00 2001
From: Fernando Nasser <fnasser@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [rfc] FREEIF -> xfree()
Date: Thu, 18 Jan 2001 07:52:00 -0000
Message-id: <3A671126.61DB3079@cygnus.com>
References: <3A6646C0.CDAFD1A4@cygnus.com>
X-SW-Source: 2001-01/msg00175.html
Content-length: 3280

Andrew Cagney wrote:
> 
> Continuing the move to xfree().
> Comments?
> 

That is what we decided to do, as far as I remember.

Fernando


>         Andrew
> 
>                                                   ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Thu Jan 18 12:25:06 2001  Andrew Cagney  <cagney@b1.cygnus.com>
> 
>         * varobj.c (FREEIF): Delete macro.
>         (varobj_set_value, free_variable): Replace FREEIF with ``xfree''
>         call.
> 
> Index: varobj.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/varobj.c,v
> retrieving revision 1.14
> diff -p -r1.14 varobj.c
> *** varobj.c    2000/12/15 01:01:51     1.14
> --- varobj.c    2001/01/18 01:27:58
> *************** static int rootcount = 0;       /* number of r
> *** 391,401 ****
>   /* Pointer to the varobj hash table (built at run time) */
>   static struct vlist **varobj_table;
> 
> - #if defined(FREEIF)
> - #undef FREEIF
> - #endif
> - #define FREEIF(x) if (x != NULL) free((char *) (x))
> -
>   /* Is the variable X one of our "fake" children? */
>   #define CPLUS_FAKE_CHILD(x) \
>   ((x) != NULL && (x)->type == NULL && (x)->value == NULL)
> --- 391,396 ----
> *************** varobj_set_value (struct varobj *var, ch
> *** 788,794 ****
>         if (!gdb_evaluate_expression (exp, &value))
>         {
>           /* We cannot proceed without a valid expression. */
> !         FREEIF (exp);
>           return 0;
>         }
> 
> --- 783,789 ----
>         if (!gdb_evaluate_expression (exp, &value))
>         {
>           /* We cannot proceed without a valid expression. */
> !         xfree (exp);
>           return 0;
>         }
> 
> *************** free_variable (struct varobj *var)
> *** 1353,1364 ****
>     if (var->root->rootvar == var)
>       {
>         free_current_contents ((char **) &var->root->exp);
> !       FREEIF (var->root);
>       }
> 
> !   FREEIF (var->name);
> !   FREEIF (var->obj_name);
> !   FREEIF (var);
>   }
> 
>   static void
> --- 1348,1359 ----
>     if (var->root->rootvar == var)
>       {
>         free_current_contents ((char **) &var->root->exp);
> !       xfree (var->root);
>       }
> 
> !   xfree (var->name);
> !   xfree (var->obj_name);
> !   xfree (var);
>   }
> 
>   static void

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From fnasser@cygnus.com Thu Jan 18 08:01:00 2001
From: Fernando Nasser <fnasser@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: Christopher Faylor <cgf@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Thu, 18 Jan 2001 08:01:00 -0000
Message-id: <3A671351.3C33ADFF@cygnus.com>
References: <Pine.SUN.3.91.1010118104033.3768K-100000@is>
X-SW-Source: 2001-01/msg00176.html
Content-length: 825

Eli Zaretskii wrote:
> 
> On Wed, 17 Jan 2001, Christopher Faylor wrote:
> 
> > What does everyone think about setting a "vote system" for this kind
> > of contingency?
> 
> Voting doesn't sound right, if a simple majority can win.  I think if
> a patch draws opposition, it should be rejected even if the opposing
> parties are in the minority.
> 

This situation where the minority rules is commonly referred to as
"dictatorship".

Yes, because if any opposition causes the rejection of a patch, any individual
can make his/her preferences prevail by systematically "opposing" to patches
that go against his believes. 

I think you must refine your definition of "opposition".

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From eliz@is.elta.co.il Thu Jan 18 08:25:00 2001
From: Eli Zaretskii <eliz@is.elta.co.il>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: Christopher Faylor <cgf@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Thu, 18 Jan 2001 08:25:00 -0000
Message-id: <Pine.SUN.3.91.1010118181831.8466B-100000@is>
References: <3A671351.3C33ADFF@cygnus.com>
X-SW-Source: 2001-01/msg00177.html
Content-length: 450

On Thu, 18 Jan 2001, Fernando Nasser wrote:

> if any opposition causes the rejection of a patch, any individual
> can make his/her preferences prevail by systematically "opposing" to patches
> that go against his believes.

I assume that individuals with such attitude are absent from this fine 
forum.  I have yet to see any sign of such an approach from anyone here.

Therefore, I don't think we need to consider such a possibility as a
real one.
From ac131313@cygnus.com Thu Jan 18 08:34:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: matthew green <mrg@cygnus.com>
Cc: Fernando Nasser <fnasser@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: patch for compilers that don't define "unix"
Date: Thu, 18 Jan 2001 08:34:00 -0000
Message-id: <3A671A63.68AD4A22@cygnus.com>
References: <8062.979583347@cygnus.com>
X-SW-Source: 2001-01/msg00178.html
Content-length: 1735

matthew green wrote:
> 
> 
>    This is not the proper fix though.  The rdi-share subdirectory is supposed to
>    contain code shared with ARM, so we shouldn't make local modifications in there
>    (unless absolutely necessary).
> 
> how about this then?  tested on netbsd/i386 and solaris 2.6.  you'll need to
> regenerate `configure' after applying this patch.
> 
> thanks.
> 
> 2001-01-15  matthew green  <mrg@redhat.com>
> 
>         * configure.in: Define missing `__unix' if `__unix__' is present.
>         * configure: Regenerate.

I think this is wrong (I actually prefered the original patch).
GDB's build process should not be defining symbols that polute the
system name space (anything with a leading double ``__'').

	enjoy,
		Andrew


> Index: configure.in
> ===================================================================
> RCS file: /cvs/src/src/gdb/configure.in,v
> retrieving revision 1.53
> diff -p -r1.53 configure.in
> *** configure.in        2000/12/21 16:16:17     1.53
> --- configure.in        2001/01/15 18:21:54
> *************** if test x${want_included_regex} = xtrue;
> *** 703,708 ****
> --- 703,718 ----
>       AC_DEFINE(USE_INCLUDED_REGEX)
>   fi
>   AC_SUBST(REGEX)
> +
> + # NetBSD compiler defines __unix__ only; rdi-share needs __unix.
> + AC_CACHE_CHECK([for NetBSD [__unix__]], gdb_cv_missing_netbsd___unix,
> + [AC_EGREP_CPP(lose, [
> + #if defined (__unix__) || !defined (__unix)
> + lose
> + #endif],[gdb_cv_missing_netbsd___unix=yes],[gdb_cv_missing_netbsd___unix=no])])
> + if test x$gdb_cv_missing_netbsd___unix = xyes; then
> +   CFLAGS="$CFLAGS -D__unix"
> + fi
> 
>   # In the Cygwin environment, we need some additional flags.
>   AC_CACHE_CHECK([for cygwin], gdb_cv_os_cygwin,
From cgf@redhat.com Thu Jan 18 09:27:00 2001
From: Christopher Faylor <cgf@redhat.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: Fernando Nasser <fnasser@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Thu, 18 Jan 2001 09:27:00 -0000
Message-id: <20010118122723.A31930@redhat.com>
References: <3A671351.3C33ADFF@cygnus.com> <Pine.SUN.3.91.1010118181831.8466B-100000@is>
X-SW-Source: 2001-01/msg00179.html
Content-length: 749

On Thu, Jan 18, 2001 at 06:21:18PM +0200, Eli Zaretskii wrote:
>
>On Thu, 18 Jan 2001, Fernando Nasser wrote:
>
>> if any opposition causes the rejection of a patch, any individual
>> can make his/her preferences prevail by systematically "opposing" to patches
>> that go against his believes.
>
>I assume that individuals with such attitude are absent from this fine 
>forum.  I have yet to see any sign of such an approach from anyone here.
>
>Therefore, I don't think we need to consider such a possibility as a
>real one.

I agree.  I was really thinking of this as a special case situation where
we could get patches into gdb when the patch maintainer is inexplicably
absent.

If *anyone* disagrees with the patch then it shouldn't go in.

cgf
From dberlin@redhat.com Thu Jan 18 13:42:00 2001
From: Daniel Berlin <dberlin@redhat.com>
To: Christopher Faylor <cgf@redhat.com>
Cc: Eli Zaretskii <eliz@is.elta.co.il>, Fernando Nasser <fnasser@cygnus.com>, <gdb-patches@sources.redhat.com>
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Thu, 18 Jan 2001 13:42:00 -0000
Message-id: <Pine.LNX.4.31.0101181329510.15385-100000@www.cgsoftware.com>
References: <20010118122723.A31930@redhat.com>
X-SW-Source: 2001-01/msg00180.html
Content-length: 1371

On Thu, 18 Jan 2001, Christopher Faylor wrote:

> On Thu, Jan 18, 2001 at 06:21:18PM +0200, Eli Zaretskii wrote:
> >
> >On Thu, 18 Jan 2001, Fernando Nasser wrote:
> >
> >> if any opposition causes the rejection of a patch, any individual
> >> can make his/her preferences prevail by systematically "opposing" to patches
> >> that go against his believes.
> >
> >I assume that individuals with such attitude are absent from this fine
> >forum.  I have yet to see any sign of such an approach from anyone here.
> >
> >Therefore, I don't think we need to consider such a possibility as a
> >real one.
>
> I agree.  I was really thinking of this as a special case situation where
> we could get patches into gdb when the patch maintainer is inexplicably
> absent.
>
> If *anyone* disagrees with the patch then it shouldn't go in.
>

Of course. But you have to admit, the situation we just had, as Jim
pointed out, makes GDB look *really* bad.
Maybe some rule about checking "obvious" bug fixes in that relate to
*your* earlier patches?
That way, you ccan fix something that your patch may have broke
accidently, as long as the fix is obvious?
I'm assuming you waited a week, and heard no response from a maintainer at
all, but no opposition from anyone else, either.


I'm not trying to handle large patches here, just 2 or 3 line fixes that
can have a major effect.
--Dan


  parent reply	other threads:[~2001-01-17 13:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200101121935.LAA03678@scv2.apple.com>
2001-01-12 12:13 ` Fernando Nasser
2001-01-17 13:09 ` Elena Zannoni
     [not found]   ` <20010117161229.B15404@redhat.com>
2001-01-17 13:55     ` Fernando Nasser [this message]
     [not found] <Pine.SUN.3.91.1010118181831.8466B-100000@is>
     [not found] ` <3A677652.FA74EAD0@neurizon.net>
     [not found]   ` <6480-Fri19Jan2001122012+0200-eliz@is.elta.co.il>
2001-01-19  8:25     ` Chris Faylor
     [not found] <200101172157.QAA21576@texas.cygnus.com>
     [not found] ` <14950.6503.362049.921003@kwikemart.cygnus.com>
2001-01-18 15:35   ` Jim Blandy
     [not found] <B6889200.268C%jingham@apple.com>
2001-01-15 12:14 ` Fernando Nasser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3A6614B3.DCB68787@cygnus.com \
    --to=fnasser@cygnus.com \
    --cc=cgf@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox