From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: Elena Zannoni Cc: David Taylor , Christopher Faylor , gdb-patches@sources.redhat.com Subject: Re: [patch] fix for infinite recursion in lookup_symbol Date: Thu, 18 Jan 2001 15:35:00 -0000 Message-id: References: <200101172157.QAA21576@texas.cygnus.com> <14950.6503.362049.921003@kwikemart.cygnus.com> X-SW-Source: 2001-01/msg00185.html 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 To: Jim Blandy Cc: Elena Zannoni , David Taylor , Christopher Faylor , 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> 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 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 To: Nick Clifton 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 > > * 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 To: GDB Patches 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 > > * 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 To: Nick Clifton , Richard Earnshaw Cc: GDB Patches , SID Discussion 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 < < * 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 * 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 To: GDB Patches 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 > > * 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" 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> <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 > > 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" 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: X-SW-Source: 2001-01/msg00192.html Content-length: 1022 > Date: Thu, 18 Jan 2001 13:32:30 -0500 (EST) > From: Daniel Berlin > > > > 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" 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: <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 > > 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 To: GDB Patches 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 * 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: 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