Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: David Taylor <taylor@cygnus.com>,
	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 15:35:00 -0000	[thread overview]
Message-ID: <np1yu0tow1.fsf@zwingli.cygnus.com> (raw)
In-Reply-To: <14950.6503.362049.921003@kwikemart.cygnus.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 13276 bytes --]

I've committed Jim Ingham's fix.

Folks, I do apologize.  For partly personal reasons, I've been very
much in the ozone regarding almost every GDB-related matter for quite
some time.  I'll try to shape up.

Ideally, I'd be ready to pass judgement on whether the famous October
12 changes should be reverted, but I don't feel like I have a handle
on the situation at the moment.  I'll try to make a real judgement on
the issue tomorrow.  In the meantime, Jim I's patch seems perfectly
safe.
From fnasser@redhat.com Thu Jan 18 15:58:00 2001
From: Fernando Nasser <fnasser@redhat.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, David Taylor <taylor@cygnus.com>, 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 15:58:00 -0000
Message-id: <3A6782C9.8DA3BB4B@redhat.com>
References: <200101172157.QAA21576@texas.cygnus.com> <14950.6503.362049.921003@kwikemart.cygnus.com> <np1yu0tow1.fsf@zwingli.cygnus.com>
X-SW-Source: 2001-01/msg00186.html
Content-length: 218

Jim Blandy wrote:
> 
> I've committed Jim Ingham's fix.
> 

Thank you. 

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From nickc@redhat.com Thu Jan 18 20:07:00 2001
From: Nick Clifton <nickc@redhat.com>
To: ac131313@cygnus.com
Cc: peter.targett@arccores.com, gdb-patches@sources.redhat.com
Subject: Re: RFA: Fix to build arc-tdep.c with new ARC machine numbers
Date: Thu, 18 Jan 2001 20:07:00 -0000
Message-id: <200101190407.UAA01868@elmo.cygnus.com>
X-SW-Source: 2001-01/msg00187.html
Content-length: 2755

Hi Andrew, 

  I am forwarding your message to Peter Taggert, who contributed the
  ARC rewrite.  I will check in the current GDB patch, since it at
  least allows the toolchain to build for now.

Cheers
	Nick
  
------- Start of forwarded message -------
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

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);
------- End of forwarded message -------
From ac131313@cygnus.com Thu Jan 18 21:41:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [rfc] FREEIF -> xfree()
Date: Thu, 18 Jan 2001 21:41:00 -0000
Message-id: <3A67D303.3B04683A@cygnus.com>
References: <3A6646C0.CDAFD1A4@cygnus.com>
X-SW-Source: 2001-01/msg00188.html
Content-length: 259

Andrew Cagney wrote:

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

I've checked this in.

	Andrew
From ac131313@cygnus.com Thu Jan 18 23:50:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Nick Clifton <nickc@cygnus.com>, Richard Earnshaw <rearnsha@arm.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>, SID Discussion <sid@sources.redhat.com>
Subject: dejagnu hang from target.exp (prune_warnings)
Date: Thu, 18 Jan 2001 23:50:00 -0000
Message-id: <3A67F120.30D17FF6@cygnus.com>
X-SW-Source: 2001-01/msg00189.html
Content-length: 2276

The change:

< 2001-01-12  Richard Earnshaw  <rearnsha@arm.com>
< 
<       * target.exp (prune_warnings): Prune warnings from NetBSD
linker.
< 

checked in by NickC causes dejagnu to hang (or to at least take a very
very very very very long walk) when the compiler generates lots of
output.  Looking at the patch:

-     # Or the NetBSD ones.
-     regsub -all "(^|\n)(.*:\[0-9\]+: warning: \[^\n\]* possibly used
unsafely, use \[^\n\]*\n?)" $text "\\1" text
-     regsub -all "(^|\n)(.*: warning: reference to compatibility
glob\[^\n\]*\n?)" $text "\\1" text

that leading ``.*'' is just too generous :-(

The attatched stops the problem for me.  Can someone please confirm this
doesn't break on NetBSD.

	enjoy,
		Andrew
Fri Jan 19 18:37:19 2001  Andrew Cagney  <cagney@b1.cygnus.com>

	* lib/target.exp (prune_warnings): Avoid ``.*'' in NetBSD warnings
 	pattern.

Index: lib/target.exp
===================================================================
RCS file: /cvs/src/src/dejagnu/lib/target.exp,v
retrieving revision 1.7
diff -p -r1.7 target.exp
*** target.exp	2001/01/12 18:13:40	1.7
--- target.exp	2001/01/19 07:39:47
*************** proc prune_warnings { text } {
*** 262,269 ****
      regsub -all "(^|\n)(ld(|32|64): Giving up.*Use -wall\[^\n\]*\n?)+" $text "\\1" text
  
      # Or the NetBSD ones.
!     regsub -all "(^|\n)(.*:\[0-9\]+: warning: \[^\n\]* possibly used unsafely, use \[^\n\]*\n?)" $text "\\1" text
!     regsub -all "(^|\n)(.*: warning: reference to compatibility glob\[^\n\]*\n?)" $text "\\1" text
  
      # GNU ld warns about functions marked as dangerous in GNU libc.
      regsub -all "(^|\n)\[^\n\]*: In function\[^\n\]*\n\[^\n\]\[^\n\]*function is dangerous\[^\n\]*" $text "" text
--- 262,269 ----
      regsub -all "(^|\n)(ld(|32|64): Giving up.*Use -wall\[^\n\]*\n?)+" $text "\\1" text
  
      # Or the NetBSD ones.
!     regsub -all "(^|\n)(\[^\n\]*:\[0-9\]+: warning: \[^\n\]* possibly used unsafely, use \[^\n\]*\n?)" $text "\\1" text
!     regsub -all "(^|\n)(\[^\n\]*: warning: reference to compatibility glob\[^\n\]*\n?)" $text "\\1" text
  
      # GNU ld warns about functions marked as dangerous in GNU libc.
      regsub -all "(^|\n)\[^\n\]*: In function\[^\n\]*\n\[^\n\]\[^\n\]*function is dangerous\[^\n\]*" $text "" text
From ac131313@cygnus.com Fri Jan 19 00:01:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [rfc] Replace STRCMP() with strcmp()
Date: Fri, 19 Jan 2001 00:01:00 -0000
Message-id: <3A67F3C5.A9B5C392@cygnus.com>
References: <3A664D3D.62952710@cygnus.com>
X-SW-Source: 2001-01/msg00190.html
Content-length: 622

Andrew Cagney wrote:

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

FYI,

I've checked this in.

	Andrew
From eliz@is.elta.co.il Fri Jan 19 01:46:00 2001
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: cgf@redhat.com
Cc: fnasser@cygnus.com, gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Fri, 19 Jan 2001 01:46:00 -0000
Message-id: <2110-Fri19Jan2001114250+0200-eliz@is.elta.co.il>
References: <3A671351.3C33ADFF@cygnus.com> <Pine.SUN.3.91.1010118181831.8466B-100000@is> <20010118122723.A31930@redhat.com>
X-SW-Source: 2001-01/msg00191.html
Content-length: 238

> Date: Thu, 18 Jan 2001 12:27:23 -0500
> From: Christopher Faylor <cgf@redhat.com>
> 
> If *anyone* disagrees with the patch then it shouldn't go in.

Well, there is, of course, the possibility of talking the opposition
into agreeing...
From eliz@is.elta.co.il Fri Jan 19 02:03:00 2001
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: dberlin@redhat.com
Cc: cgf@redhat.com, fnasser@cygnus.com, gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Fri, 19 Jan 2001 02:03:00 -0000
Message-id: <2950-Fri19Jan2001120038+0200-eliz@is.elta.co.il>
References: <Pine.LNX.4.31.0101181329510.15385-100000@www.cgsoftware.com>
X-SW-Source: 2001-01/msg00192.html
Content-length: 1022

> Date: Thu, 18 Jan 2001 13:32:30 -0500 (EST)
> From: Daniel Berlin <dberlin@redhat.com>
> >
> > 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.

I don't agree.  I didn't follow the discussion about this particular
problem, but if the relevant maintainer goes off-line, and some of the
other maintainers have reservations about a suggested patch in the
absent maintainer's area, refraining from committing that patch is
IMHO a prudent thing to do.

In such a situation, you have several possible alternatives:

  - talk the opposition into agreeing to the patch;
  - suggest an alternative patch which avoids the problems which
    triggered the opposition;
  - wait for the maintainer to reappear and decide what to do.
From eliz@is.elta.co.il Fri Jan 19 02:23:00 2001
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: sjohnson@neurizon.net
Cc: fnasser@cygnus.com, cgf@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Fri, 19 Jan 2001 02:23:00 -0000
Message-id: <6480-Fri19Jan2001122012+0200-eliz@is.elta.co.il>
References: <Pine.SUN.3.91.1010118181831.8466B-100000@is> <3A677652.FA74EAD0@neurizon.net>
X-SW-Source: 2001-01/msg00193.html
Content-length: 228

> Date: Fri, 19 Jan 2001 09:03:47 +1000
> From: Steven Johnson <sjohnson@neurizon.net>
> 
> If there are "NO" votes, then they should be qualified with reasons.

Yes, of course.  I think everybody here already does that anyway.
From ac131313@cygnus.com Fri Jan 19 02:29:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [rfc] MAINTAINERS target buildable list and configure.in wind-back
Date: Fri, 19 Jan 2001 02:29:00 -0000
Message-id: <3A681667.A2734973@cygnus.com>
References: <3A66E90C.3162F8B5@cygnus.com>
X-SW-Source: 2001-01/msg00194.html
Content-length: 431

FYI,

I've checked this in.  It allows me to check a multi-arch patch I'm
about to post.  If you fix a build problem please please feel free to up
date it.

	Andrew

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.
From DJBARROW@de.ibm.com Fri Jan 19 06:34:00 2001
From: DJBARROW@de.ibm.com
To: gdb-patches@sourceware.cygnus.com
Subject: question
Date: Fri, 19 Jan 2001 06:34:00 -0000
Message-id: <C12569D9.004FF453.00@d12mta09.de.ibm.com>
X-SW-Source: 2001-01/msg00195.html
Content-length: 371

Hi,
Do we now have to check out gdb bfd binutils readline etc separately as
they are no longer appear to be in the gdb
repository ? & if so could someone of you please update the getting.html.

D.J. Barrow Linux for S/390 kernel developer
eMail: djbarrow@de.ibm.com,barrow_dj@yahoo.com
Phone: +49-(0)7031-16-2583
IBM Germany Lab, Schönaicherstr. 220, 71032 Böblingen



       reply	other threads:[~2001-01-18 15:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200101172157.QAA21576@texas.cygnus.com>
     [not found] ` <14950.6503.362049.921003@kwikemart.cygnus.com>
2001-01-18 15:35   ` Jim Blandy [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] <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
     [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=np1yu0tow1.fsf@zwingli.cygnus.com \
    --to=jimb@zwingli.cygnus.com \
    --cc=cgf@redhat.com \
    --cc=ezannoni@cygnus.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=taylor@cygnus.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