* Re: [patch] fix for infinite recursion in lookup_symbol [not found] ` <14950.6503.362049.921003@kwikemart.cygnus.com> @ 2001-01-18 15:35 ` Jim Blandy 0 siblings, 0 replies; 6+ messages in thread From: Jim Blandy @ 2001-01-18 15:35 UTC (permalink / raw) To: Elena Zannoni; +Cc: David Taylor, Christopher Faylor, gdb-patches [-- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <Pine.SUN.3.91.1010118181831.8466B-100000@is>]
[parent not found: <3A677652.FA74EAD0@neurizon.net>]
[parent not found: <6480-Fri19Jan2001122012+0200-eliz@is.elta.co.il>]
* Re: [patch] fix for infinite recursion in lookup_symbol [not found] ` <6480-Fri19Jan2001122012+0200-eliz@is.elta.co.il> @ 2001-01-19 8:25 ` Chris Faylor 0 siblings, 0 replies; 6+ messages in thread From: Chris Faylor @ 2001-01-19 8:25 UTC (permalink / raw) To: Eli Zaretskii; +Cc: sjohnson, fnasser, gdb-patches On Fri, Jan 19, 2001 at 12:20:12PM +0200, Eli Zaretskii wrote: >> 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. Right. I really don't think we have to worry about the "jerk" scenario. Everyone here is pretty reasonable. cgf From fnasser@cygnus.com Fri Jan 19 09:20:00 2001 From: Fernando Nasser <fnasser@cygnus.com> To: Andrew Cagney <ac131313@cygnus.com> Cc: matthew green <mrg@cygnus.com>, Fernando Nasser <fnasser@redhat.com>, gdb-patches@sources.redhat.com Subject: Re: patch for compilers that don't define "unix" Date: Fri, 19 Jan 2001 09:20:00 -0000 Message-id: <3A68773E.208C140C@cygnus.com> References: <8062.979583347@cygnus.com> <3A671A63.68AD4A22@cygnus.com> X-SW-Source: 2001-01/msg00198.html Content-length: 2658 Andrew Cagney wrote: > > 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 ``__''). > FYI, the original patch did the same thing: defined the same symbol, just in a more restricted scope. So your argument would apply to it as well. But you misunderstood Matthew's intention. He is not inventing a new symbol. He is defining a symbol that newer versions of netbsd do not define any longer. The naming at least is correct. He is defining exactly the same symbol that used to be defined by previous versions and it is a system symbol, that belongs in the system space, with a leading "__". Anyway, I will work with Matthew to keep the change restricted to the rdi-share subdirectory so we leave gdb/configure.in alone. > 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, -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 From jingham@apple.com Fri Jan 19 10:50:00 2001 From: Jim Ingham <jingham@apple.com> To: gdb-patches@sources.redhat.com Subject: Re: gdb-patches Digest 19 Jan 2001 14:34:08 -0000 Issue 519 Date: Fri, 19 Jan 2001 10:50:00 -0000 Message-id: <200101191849.KAA25663@scv1.apple.com> References: <979914848.9079.ezmlm@sources.redhat.com> X-SW-Source: 2001-01/msg00199.html Content-length: 2627 Eli, I think the situation was a little different than you are percieving. Some patches were checked in. I also didn't follow the discussion closely at the time. Apparently the patches were controversial, and there was some contention about whether they should stay in or not. But for the nonce they were in. And given that we mostly know that JimB is working on another very important and cool project right now (how is subversions going by the way) it was clear that it would take a little while to sort this out. HOWEVER, the patch (and thus the current state of gdb) had an obvious gaffe that caused gdb to crash in a pretty common usage. Moreover, apparently both the bug and the fix were known pretty soon after the original patch was checked in. To make matters worse, the fix for the crashing bug was a no-brainer - probably just a cut & paste error. So it was important to decouple the discussion of whether the overall patch should be reverted or not from the decision to check in a fix that kept gdb as it stood in the CVS repository from crashing on people. This sort of case may very well arise again, since it was not the result of bad will on anybody's part, as far as I can tell. And regardless of larger design concerns we really should have a way to expedite fixes in this context, so that gdb stays pretty reliable most of the time. It was unreliable for C++ debugging for two or three months. This is bad... Jim >> 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. -- Jim Ingham jingham@apple.com Developer Tools - gdb Apple Computer From eliz@is.elta.co.il Fri Jan 19 11:29:00 2001 From: "Eli Zaretskii" <eliz@is.elta.co.il> To: jingham@apple.com Cc: gdb-patches@sources.redhat.com Subject: Re: gdb-patches Digest 19 Jan 2001 14:34:08 -0000 Issue 519 Date: Fri, 19 Jan 2001 11:29:00 -0000 Message-id: <968-Fri19Jan2001212516+0200-eliz@is.elta.co.il> References: <200101191849.KAA25663@scv1.apple.com> X-SW-Source: 2001-01/msg00200.html Content-length: 1591 > Date: Fri, 19 Jan 2001 10:49:56 -0800 > From: Jim Ingham <jingham@apple.com> > > HOWEVER, the patch (and thus the current state of gdb) had an obvious > gaffe that caused gdb to crash in a pretty common usage. Moreover, > apparently both the bug and the fix were known pretty soon after the > original patch was checked in. To make matters worse, the fix for the > crashing bug was a no-brainer - probably just a cut & paste error. > > So it was important to decouple the discussion of whether the overall > patch should be reverted or not from the decision to check in a fix that > kept gdb as it stood in the CVS repository from crashing on people. Was someone opposed to get this fixed in the way suggested by whoever proposed the fix? If there was no opposition, I don't see how the situation you described contradicts a principle I was proposing. > This sort of case may very well arise again, since it was not the result > of bad will on anybody's part, as far as I can tell. And regardless of > larger design concerns we really should have a way to expedite fixes in > this context, so that gdb stays pretty reliable most of the time. I agree that we must have a way to take action when the responsible maintainer is unavailable. I just think that when considering changes in areas that aren't areas of our immediate expertise, we should exercise more cautious approach. If there are people who are experts in some area, they can step forward as back-up maintainers, so that, shall the main maintainer become unavailable, changes can still be quickly committed. From ac131313@cygnus.com Fri Jan 19 14:54:00 2001 From: Andrew Cagney <ac131313@cygnus.com> To: rearnsha@arm.com Cc: Nick Clifton <nickc@cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>, SID Discussion <sid@sources.redhat.com> Subject: Re: dejagnu hang from target.exp (prune_warnings) Date: Fri, 19 Jan 2001 14:54:00 -0000 Message-id: <3A68C4FA.BA8FF50A@cygnus.com> References: <200101191458.OAA06282@cam-mail2.cambridge.arm.com> X-SW-Source: 2001-01/msg00201.html Content-length: 312 Richard Earnshaw wrote: > > Fri Jan 19 18:37:19 2001 Andrew Cagney <cagney@b1.cygnus.com> > > * lib/target.exp (prune_warnings): Avoid ``.*'' in NetBSD warnings > pattern. > > OK. Still filters out the relevant warnings from the g77 regression suite. Thanks! I've checked it in. Andrew From ac131313@cygnus.com Fri Jan 19 15:52:00 2001 From: Andrew Cagney <ac131313@cygnus.com> To: DJBARROW@de.ibm.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: question Date: Fri, 19 Jan 2001 15:52:00 -0000 Message-id: <3A68D2BA.7268D4DF@cygnus.com> References: <C12569D9.004FF453.00@d12mta09.de.ibm.com> X-SW-Source: 2001-01/msg00202.html Content-length: 391 DJBARROW@de.ibm.com wrote: > > 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. Hmm, GDB lives in the unified SRC repository with bfd and binutils. See: http://sources.redhat.com/gdb/#download Do you have a URL for getting.html? Andrew From bje@redhat.com Sat Jan 20 04:28:00 2001 From: Ben Elliston <bje@redhat.com> To: <gdb-patches@sources.redhat.com>, <sid@sources.redhat.com> Subject: [DejaGNU patch] Re-document --mail Date: Sat, 20 Jan 2001 04:28:00 -0000 Message-id: <Pine.LNX.4.31.0101202327010.25471-100000@moshpit.cygnus.com> X-SW-Source: 2001-01/msg00203.html Content-length: 1625 Over the years, the --mail option has been slowly disappearing from documentation. Okay to commit? 2001-01-20 Ben Elliston <bje@redhat.com> * runtest.exp (usage): Replace --mail in usage output. * doc/runtest.1: Re-document --mail option, which was erroneously removed from this man page in 1994. Index: runtest.exp =================================================================== RCS file: /cvs/cvsfiles/devo/dejagnu/runtest.exp,v retrieving revision 1.153 diff -u -r1.153 runtest.exp --- runtest.exp 1999/12/02 18:51:54 1.153 +++ runtest.exp 2001/01/20 12:24:47 @@ -372,6 +372,7 @@ send_user "\t--target \[string\]\tThe canonical config name of the target board\n" send_user "\t--debug (-de)\t\tSet expect debugging ON\n" send_user "\t--help (-he)\t\tPrint help text\n" + send_user "\t--mail \[name(s)\]\tWho to mail the results to\n" send_user "\t--ignore \[name(s)\]\tThe names of specific tests to ignore\n" send_user "\t--objdir \[name\]\t\tThe test suite binary directory\n" send_user "\t--outdir \[name\]\t\tThe directory to put logs in\n" Index: doc/runtest.1 =================================================================== RCS file: /cvs/cvsfiles/devo/dejagnu/doc/runtest.1,v retrieving revision 1.7 diff -u -r1.7 runtest.1 --- runtest.1 1998/12/30 20:36:57 1.7 +++ runtest.1 2001/01/20 12:24:48 @@ -53,8 +53,9 @@ .TP .BI --ignore \ test1.exp\ test2.exp\ ... Do not run the specified tests. +.BI --mail \ \'name1\ name2\ ...\' Electronic mail addresses to receive test results. -.TP +.TP .BI --name \ hostname The network hostname of the target board. .TP ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <B6889200.268C%jingham@apple.com>]
* Re: [patch] fix for infinite recursion in lookup_symbol [not found] <B6889200.268C%jingham@apple.com> @ 2001-01-15 12:14 ` Fernando Nasser 0 siblings, 0 replies; 6+ messages in thread From: Fernando Nasser @ 2001-01-15 12:14 UTC (permalink / raw) To: Jim Ingham; +Cc: Daniel Berlin, gdb-patches I just would like to add my 2cents to a few of Jim's remarks: Jim Ingham wrote: > > Daniel, > > >> I understand that there is some argument over whether the current > >> implementation of C++ symbol lookup is the right one, but while it is in > >> place, simple fixes to it need to get into the sources quickly. > > > > I'd happily check them in under an obvious bugfix rule, but I don't want > > to step on any toes. > > I had enough fun doing that trying to figure out what exact areas of code > > C++ maintainer covers, and I still couldn't tell you. > > If someone with definite maintainership over the symbol tables says I can > > check in the fixes, i'll do it. Otherwise, i won't. > > Sorry. > > I sympathize, but in this case the fix really is trivial... This one really > does fall under the obvious bugfix rule if any fix does... > People were questioning earlier today if such rule really exists. If it does not we are doomed. Specially with the current maintainers response time (including me -- we all have our hands full). We need a way to fix things quickly. If it needs a better fix it should be properly documented so people get to it as soon as they can. We cannot just leave things broken!!! If this is an attempt to force volunteers to make extra work and do code improvements and cleanups is not working. People are just giving up and leaving things broken. They are probably adding the fixes to their own copies and many other developers/users are suffering unnecessarily. > > > > Which explains why you keep mentioning users, when the bug only exists in > > CVS. > > This is a very bad idea to be doing. > > I really don't understand this. What else are we supposed to be basing our > sources on? There are two options here, apply patches from the Patches list > in advance of their acceptance, or just stick with "official" releases (i.e. > 5.0) > > There are lots of good patches, and lots of bad ones, in the patches mailing > list. It is better, I think, for us to let the "experts" in the Maintainers > group sort them out, and then use the results of this vetting process. That > IS what the whole Maintainer's (or Helpers??) structure is for. Seems like > subverting this process will just cause us more trouble. > > On the other hand, does anyone think an unmodified 5.0 is a good release to > base our efforts on? It has been around for a while now, and has its own > share of bugs that HAVE been fixed. In any case, you don't really WANT most > of your gdb users to stick with the 5.0 release, do you? That would mean > that the CVS changes are being tested by some set of Red Hat customers, and > that is about all. That would not be a very good idea. > GDB 5.0 is so old and so broken (at least Insight is) that it is useless to many people. If you look at the insight mailing list archives, people have been forced to download newer snapshots or even the CVS version because they just can't use the 5.0. If we had created a way to have a set of patches to 5.0 available, or even created some updated 5.0 releases with just bug fixes (no new feature -- bug fixes applied to the old 5.0 code base) this situation could be better. Even though, there would be things that the fixes would be to extensive to retrofit, and still people would have to resort to newer sources. And developers also waste many hours because of known bugs with minor fixes that just werent comitted. No matter how I look at it I can't find a good reason to leave bugs laying around when a fix is known. -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 From kevinb@cygnus.com Mon Jan 15 12:34:00 2001 From: Kevin Buettner <kevinb@cygnus.com> To: Fernando Nasser <fnasser@redhat.com> Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: [infrun.c] Fix to "nexti". Date: Mon, 15 Jan 2001 12:34:00 -0000 Message-id: <1010115203401.ZM6558@ocotillo.lan> References: <3A54D5D2.CCA3E45E@redhat.com> <3A59DE42.5295C9A5@cygnus.com> <3A6318BF.A9A43A10@redhat.com> <20010115113635.B26739@redhat.com> <1010115175046.ZM6315@ocotillo.lan> <3A63418D.513E833@redhat.com> <fnasser@redhat.com> X-SW-Source: 2001-01/msg00130.html Content-length: 2437 On Jan 15, 1:29pm, Fernando Nasser wrote: > Kevin Buettner wrote: > > > > On Jan 15, 11:36am, Christopher Faylor wrote: > > > > > On Mon, Jan 15, 2001 at 10:35:27AM -0500, Fernando Nasser wrote: > > > >If there is a maintainer for this code please speak up. > > > > > > > >Otherwise I will check this in under the "obvious fix" rule. > > > > > > Do we really have an "obvious fix" rule? It seems that there is > > > some confusion on this issue. > > > > We do not have an "obvious fix" rule. See > > > > http://sources.redhat.com/ml/gdb-patches/2000-04/msg00468.html > > > > If you go throughout the list you'll find that it has been mentioned and > invoked several times in other messages. It is not well defined though, > and it does not seem to be written anywhere either. Would you mind pointing a few of these out? I've searched for "obvious" in the gdb-patches archive, but it generates a lot of hits. (I'm curious about whether it's "blanket write privs" maintainers who are invoking this rule.) > As it is not written what to do when the maintainers do not respond and > something is broken. Do we keep downloading rotten code? These bugs > are very costly in that people waste hours of work because of them. I don't know what the right answer is. With regard to the infrun.c patch, however, I did take a look at it and it wasn't clear to me that it was "obviously" right. I'm not saying it's wrong either, but that code is complicated and requires some study. > The message above mentions a problem with regards to small fixes in > codes outside one's maintainership that go wrong. Sometimes > the original problem is fixed but some other is created. > That is why we use CVS. The change can be reversed and the maintainer > (when he/she shows up) has a complete record of what has been changed > and > why (in addition to the list archives). > > I don't know what is the better/right solution to the problem, but we do > have a problem now with regarding to bug fixes, specially small fix to > harmful ones. We do need a fast track to them and even consider > temporary > fixes (properly marked with FIXME and entries in the TODO file). If those of us working on gdb could have some of their time freed up to spend on our maintainership duties, that will clearly be a step in the right direction. But I agree that we ought to have a process in place to deal with the situations you describe. From geoffk@geoffk.org Mon Jan 15 15:29:00 2001 From: Geoff Keating <geoffk@geoffk.org> To: gdb-patches@sources.redhat.com Subject: patch for ppc sim to fix open() Date: Mon, 15 Jan 2001 15:29:00 -0000 Message-id: <200101152329.PAA00837@geoffk.org> X-SW-Source: 2001-01/msg00131.html Content-length: 1960 This makes the sim's emulation of the open() syscall match NetBSD, even on hosts where the constants are different. I wanted this so that Perennial tests could create temporary files. (It's also dangerous to call open() with random flag values.) -- - Geoffrey Keating <geoffk@geoffk.org> ===File ~/patches/cygnus/sim-ppcopen.patch================== 2000-12-29 Geoffrey Keating <geoffk@redhat.com> * emul_netbsd.c (do_open): Translate the flag parameter to the open syscall to the numbers supported by the host. Index: emul_netbsd.c =================================================================== RCS file: /cvs/cvsfiles/devo/sim/ppc/emul_netbsd.c,v retrieving revision 1.30 diff -u -p -r1.30 emul_netbsd.c --- emul_netbsd.c 2000/03/02 09:22:28 1.30 +++ emul_netbsd.c 2001/01/09 22:51:06 @@ -386,6 +386,7 @@ do_open(os_emul_data *emul, char *path = emul_read_string(path_buf, path_addr, PATH_MAX, processor, cia); int flags = (int)cpu_registers(processor)->gpr[arg0+1]; int mode = (int)cpu_registers(processor)->gpr[arg0+2]; + int hostflags; int status; if (WITH_TRACE && ppc_trace[trace_os_emul]) @@ -393,8 +394,25 @@ do_open(os_emul_data *emul, SYS(open); + /* Do some translation on 'flags' to match it to the host's version. */ + /* These flag values were taken from the NetBSD 1.4 header files. */ + if ((flags & 3) == 0) + hostflags = O_RDONLY; + else if ((flags & 3) == 1) + hostflags = O_WRONLY; + else + hostflags = O_RDWR; + if (flags & 0x00000008) + hostflags |= O_APPEND; + if (flags & 0x00000200) + hostflags |= O_CREAT; + if (flags & 0x00000400) + hostflags |= O_TRUNC; + if (flags & 0x00000800) + hostflags |= O_EXCL; + /* Can't combine these statements, cuz open sets errno. */ - status = open(path, flags, mode); + status = open(path, hostflags, mode); emul_write_status(processor, status, errno); } ============================================================ From jtc@redback.com Mon Jan 15 18:08:00 2001 From: jtc@redback.com (J.T. Conklin) To: gdb-patches@sourceware.cygnus.com Subject: patch to split embedded and linux sh targets Date: Mon, 15 Jan 2001 18:08:00 -0000 Message-id: <5mzogss0zd.fsf@jtc.redback.com> X-SW-Source: 2001-01/msg00132.html Content-length: 2976 I submit the enclosed patch for a approval. The current sh target, which was once a embedded only target has been made gnu/linux-specific by the inclusion of shared library support. This patch creates a embedded target (sh-*-coff*, sh-*-elf*) by moving the linux bits to its own configuration (sh-*-linux*). I haven't changed the linux config other than by renaming sh.mt to linux.mt, although I believe that support for the SH3 ROM monitor, the e7000 ICE, and perhaps the SH simulator can be removed. --jtc 2001-01-15 J.T. Conklin <jtc@redback.com> * configure/sh/embed.mt: New file. * configure/sh/linux.mt: New file. * configure/sh/sh.mt: Removed. * configure.tgt (sh-*-coff*, sh-*-elf*, sh-*-linux): New targets. (sh-*-*): Removed. Index: configure.tgt =================================================================== RCS file: /cvs/src/src/gdb/configure.tgt,v retrieving revision 1.16 diff -c -r1.16 configure.tgt *** configure.tgt 2000/12/14 20:15:45 1.16 --- configure.tgt 2001/01/16 02:01:57 *************** *** 263,269 **** rs6000-*-*) gdb_target=rs6000 ;; sh*-*-pe) gdb_target=wince ;; ! sh-*-*) gdb_target=sh ;; sparc-*-aout*) gdb_target=sparc-em ;; sparc-*-coff*) gdb_target=sparc-em ;; --- 263,271 ---- rs6000-*-*) gdb_target=rs6000 ;; sh*-*-pe) gdb_target=wince ;; ! sh-*-coff*) gdb_target=embed ;; ! sh-*-elf*) gdb_target=embed ;; ! sh-*-linux*) gdb_target=linux ;; sparc-*-aout*) gdb_target=sparc-em ;; sparc-*-coff*) gdb_target=sparc-em ;; Index: config/sh/embed.mt =================================================================== RCS file: embed.mt diff -N embed.mt *** /dev/null Tue May 5 13:32:27 1998 --- embed.mt Mon Jan 15 18:01:57 2001 *************** *** 0 **** --- 1,6 ---- + # Target: Embedded Hitachi Super-H with ICE and simulator + TDEPFILES= sh-tdep.o monitor.o sh3-rom.o remote-e7000.o ser-e7kpc.o dsrec.o + TM_FILE= tm-sh.h + + SIM_OBS = remote-sim.o + SIM = ../sim/sh/libsim.a Index: config/sh/linux.mt =================================================================== RCS file: linux.mt diff -N linux.mt *** /dev/null Tue May 5 13:32:27 1998 --- linux.mt Mon Jan 15 18:01:57 2001 *************** *** 0 **** --- 1,6 ---- + # Target: Hitachi Super-H running GNU/Linux + TDEPFILES= sh-tdep.o monitor.o sh3-rom.o remote-e7000.o ser-e7kpc.o dsrec.o solib.o solib-svr4.o + TM_FILE= tm-linux.h + + SIM_OBS = remote-sim.o + SIM = ../sim/sh/libsim.a Index: config/sh/sh.mt =================================================================== RCS file: sh.mt diff -N sh.mt *** /sourceware/cvs-tmp/cvsiq6IWP Mon Jan 15 18:01:58 2001 --- /dev/null Tue May 5 13:32:27 1998 *************** *** 1,6 **** - # Target: Hitachi Super-H with ICE and simulator - TDEPFILES= sh-tdep.o monitor.o sh3-rom.o remote-e7000.o ser-e7kpc.o dsrec.o solib.o solib-svr4.o - TM_FILE= tm-linux.h - - SIM_OBS = remote-sim.o - SIM = ../sim/sh/libsim.a --- 0 ---- -- J.T. Conklin RedBack Networks From ac131313@cygnus.com Mon Jan 15 19:39:00 2001 From: Andrew Cagney <ac131313@cygnus.com> To: Nick Duffek <nsd@redhat.com> Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] New register definition interface Date: Mon, 15 Jan 2001 19:39:00 -0000 Message-id: <3A63C202.F418E4ED@cygnus.com> References: <3A62408E.A745B2D6@cygnus.com> <200101151859.f0FIxqG05555@rtl.cygnus.com> X-SW-Source: 2001-01/msg00133.html Content-length: 2999 Nick Duffek wrote: > The same issue applies to cli-regs.c: cliregs_init() attaches memory to > each architecture even if the architecture hasn't set cliregs_info() as > its do_registers_info callback. > > Some possible solutions: > > 1. Each competing module implementation introduces a gdbarch variable > USE_<module-implementation> that architectures must set to 1 if > they're using that implementation. For example: I don't think it will scale. It is a bit like those GDB_ARCHITECTURE_IS_D10V et.al. we'd all like to get rid of. The tests should be for functionality not implementation. However, a hack of yes/no ``register_module_installed_p'' flag might be useful so that the default case (regcache) knows to not install its self. > 2. Each module introduces a gdbarch variable MODULE_<module-name> that > architectures must set to an implementation-unique value. Definitly not this one. Look at the spaghetti found in sim/common (yes I'm in part to blame for that one :-) > 3. Introduce a gdbarch interface to query function pointers. Competing > module implementations can use these to check whether they're being > used by the current architecture. For example: > > if (GET_DO_REGISTERS_INFO () != cliregs_info) > return; I don't think it should be necessary. Module implementations shouldn't be competing - once a module, for a given architecture, is selected the competing modules should never be seen again. Did I mention sim/common :-) The only exception would be where gdbarch asks the question ``has any module been installed?'' If no - install the default. > /* allocate memory */ > > To avoid the footprint of a GET_*() function for every gdbarch.sh > entry, a per-entry flag could be added that controls whether that > function is needed. 4. Add a function like: set_gdbarch_data (struct gdbarch *gdbarch, struct gdbarch_data *handle, void *value); so that instead of waiting for gdbarch to call your module, your module, as part of its set-up, calls gdbarch vis: gdbarch calls ..._gdbarch_init() -> calls your_module's_init_or_setup_or_something() -> calls set_gdbarch_data (gdbarch, your_modules_handle, your_modules_data); -> calls set_various_other_methods (...); (mumble something about fine print, memory leaks and deleting architectures :-) I wouldn't be too worried if it for the short term (for GDB that is about a year :-) build_regcache() still allocated a buffer - that is an implementation issue (like using bubble sort :-). I'm worried about interfaces not implementations :-). Just document the problem in the code and TODO files. Alternativly, like you were outlining, some sort of check to see if a competing module hasn't already been installed. Long long term, the register stuff could be combined into a group so that it are installed as a block - instead of the N separate register methods. Again, that is a separate problem. Andrew From ac131313@cygnus.com Mon Jan 15 19:44:00 2001 From: Andrew Cagney <ac131313@cygnus.com> To: Nick Duffek <nsd@redhat.com> Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] New register definition interface Date: Mon, 15 Jan 2001 19:44:00 -0000 Message-id: <3A63C32F.5031F1FB@cygnus.com> References: <3A62408E.A745B2D6@cygnus.com> <200101151859.f0FIxqG05555@rtl.cygnus.com> X-SW-Source: 2001-01/msg00134.html Content-length: 653 Nick Duffek wrote: > Speaking of gdbarch.sh changes, what do you think about the idea of > translating gdbarch.sh into C and automatically generating gdbarch.[ch] as > transient compile-time entities? Running gdbarch.sh takes about 25 > seconds on my 650MHz Pentium, and I often forget to run it after applying > or reverting patches that change it. I wish :-) The plan is to eventually have things autogenerated when GDB is configured with --enable-maintainer-mode. Unfortunatly it can't be made the default as you can bet your bottom dollar that gdbarch.sh will break on some critical platform shell :-( I'll add this to the TODO file. Andrew From bje@redhat.com Mon Jan 15 22:33:00 2001 From: Ben Elliston <bje@redhat.com> To: gdb-patches@sources.redhat.com Cc: bje@redhat.com Subject: [testsuite] Contribution to testsuite/config Date: Mon, 15 Jan 2001 22:33:00 -0000 Message-id: <200101160633.f0G6X4N19524@scooby.cygnus.com> X-SW-Source: 2001-01/msg00135.html Content-length: 4961 Attached is a copy of `sid.exp' -- a config file for DejaGNU to permit GDB testing on simulators in the SID framework. Okay to commit? 2001-01-16 Ben Elliston <bje@redhat.com> * config/sid.exp: New file. # Test Framework Driver for GDB driving an external simulator # Copyright 1999 Free Software Foundation, Inc. ? # # 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. load_lib gdb.exp proc sid_start {} { global sid_spawn_id global verbose set port [lindex [split [target_info netport] ":"] 1] # Set a default endianness case [target_info multilib_flags] in { { *big-endian* *-EB* *-meb* } { set sidendian "-EB" } { *little-endian* *-EL* *-mel* } { set sidendian "-EL" } default { if {[target_info exists sim,defaultendian]} then { set sidendian [target_info sim,defaultendian] } else { warning "Unknown target endianness - assuming -EB" set sidendian "-EB" } } } # set verbosity conditionally if {$verbose > 0} then { set sidverbose "--verbose" } else { set sidverbose "" } # test to see whether to use use sid in build or install tree set use_build_tree [file exists ../../sid] if {$use_build_tree} then { set pre_spawn { global env set env(SID_LIBRARY_PATH) [join [glob "../../sid/component/*"] ":"] set env(SID) "../../sid/main/dynamic/sid" set env(MKSID) "../../sid/main/static/mksid" if {! [file exists $env(SID)]} then { error "Cannot find sid in build tree" } } set spawncmd "../../sid/bsp/[target_info sim] $sidverbose $sidendian --persistent --gdb=$port [target_info sim,options]" set post_spawn { global env unset env(SID_LIBRARY_PATH) unset env(MKSID) unset env(SID) } } else { set pre_spawn {} set spawncmd "[target_info sim] $sidverbose $sidendian --persistent --gdb=$port [target_info sim,options]" set post_spawn {} } eval $pre_spawn if {[catch "spawn $spawncmd" msg]} { perror $msg exit 1 } eval $post_spawn expect_background { -re \[^\n\]*\n { regsub "\n" $expect_out(buffer) {} msg verbose "SID: $msg" 2 } } # There should be no need to sleep to give SID time to start; # GDB would wait for a fair while for the stub to respond. sleep 4 set sid_spawn_id $spawn_id } # # Handle GDB talking to SID # proc gdb_start {} { sid_start return [default_gdb_start] } proc sid_exit {} { global sid_spawn_id if {[info exists sid_spawn_id]} { catch {exec kill [exp_pid -i $sid_spawn_id]} catch {wait -i $sid_spawn_id} unset sid_spawn_id sleep 4 } } proc gdb_exit {} { set result [default_gdb_exit] sid_exit return $result } # # gdb_target_sid # Set gdb to target the simulator # proc send_target_sid { } { # wait a little while, giving sid time to shut down & restart its # gdb socket sleep 4 send_gdb "target [target_info gdb_protocol] [target_info netport]\n" } proc gdb_target_sid { } { global gdb_prompt global exit_status send_target_sid global timeout set prev_timeout $timeout set timeout 60 verbose "Timeout is now $timeout seconds" 2 gdb_expect { -re "Remote debugging using.*$gdb_prompt" { verbose "Set target to sid" } timeout { perror "Couldn't set target for remote simulator." cleanup exit $exit_status } } set timeout $prev_timeout verbose "Timeout is now $timeout seconds" 2 } # # gdb_load -- load a file into the debugger. # return a -1 if anything goes wrong. # proc gdb_load { arg } { global verbose global loadpath global loadfile global GDB global gdb_prompt gdb_unload if [gdb_file_cmd $arg] then { return -1 } gdb_target_sid send_gdb "load\n" global timeout set prev_timeout $timeout set timeout 2400 verbose "Timeout is now $timeout seconds" 2 gdb_expect { -re ".*$gdb_prompt $" { if $verbose>1 then { send_user "Loaded $arg into $GDB\n" } set timeout 30 verbose "Timeout is now $timeout seconds" 2 return 1 } -re "$gdb_prompt $" { if $verbose>1 then { perror "GDB couldn't load." } } timeout { if $verbose>1 then { perror "Timed out trying to load $arg." } } } set timeout $prev_timeout } From fnasser@cygnus.com Tue Jan 16 08:56:00 2001 From: Fernando Nasser <fnasser@cygnus.com> To: Ben Elliston <bje@redhat.com> Cc: gdb-patches@sources.redhat.com Subject: Re: [testsuite] Contribution to testsuite/config Date: Tue, 16 Jan 2001 08:56:00 -0000 Message-id: <3A647D4B.4B343299@cygnus.com> References: <200101160633.f0G6X4N19524@scooby.cygnus.com> X-SW-Source: 2001-01/msg00136.html Content-length: 6022 Ben Elliston wrote: > > Attached is a copy of `sid.exp' -- a config file for DejaGNU to permit > GDB testing on simulators in the SID framework. Okay to commit? > Sure thanks. Fernando > 2001-01-16 Ben Elliston <bje@redhat.com> > > * config/sid.exp: New file. > > # Test Framework Driver for GDB driving an external simulator > # Copyright 1999 Free Software Foundation, Inc. ? > # > # 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. > > load_lib gdb.exp > > proc sid_start {} { > global sid_spawn_id > global verbose > > set port [lindex [split [target_info netport] ":"] 1] > > # Set a default endianness > case [target_info multilib_flags] in { > { *big-endian* *-EB* *-meb* } { set sidendian "-EB" } > { *little-endian* *-EL* *-mel* } { set sidendian "-EL" } > default { > if {[target_info exists sim,defaultendian]} then { > set sidendian [target_info sim,defaultendian] > } else { > warning "Unknown target endianness - assuming -EB" > set sidendian "-EB" > } > } > } > # set verbosity conditionally > if {$verbose > 0} then { set sidverbose "--verbose" } else { set sidverbose "" } > > # test to see whether to use use sid in build or install tree > set use_build_tree [file exists ../../sid] > > if {$use_build_tree} then { > set pre_spawn { > global env > set env(SID_LIBRARY_PATH) [join [glob "../../sid/component/*"] ":"] > set env(SID) "../../sid/main/dynamic/sid" > set env(MKSID) "../../sid/main/static/mksid" > if {! [file exists $env(SID)]} then { error "Cannot find sid in build tree" } > } > set spawncmd "../../sid/bsp/[target_info sim] $sidverbose $sidendian --persistent --gdb=$port [target_info sim,options]" > set post_spawn { > global env > unset env(SID_LIBRARY_PATH) > unset env(MKSID) > unset env(SID) > } > } else { > set pre_spawn {} > set spawncmd "[target_info sim] $sidverbose $sidendian --persistent --gdb=$port [target_info sim,options]" > set post_spawn {} > } > > eval $pre_spawn > if {[catch "spawn $spawncmd" msg]} { > perror $msg > exit 1 > } > eval $post_spawn > > expect_background { > -re \[^\n\]*\n { > regsub "\n" $expect_out(buffer) {} msg > verbose "SID: $msg" 2 > } > } > > # There should be no need to sleep to give SID time to start; > # GDB would wait for a fair while for the stub to respond. > sleep 4 > > set sid_spawn_id $spawn_id > } > > # > # Handle GDB talking to SID > # > > proc gdb_start {} { > sid_start > return [default_gdb_start] > } > > proc sid_exit {} { > global sid_spawn_id > if {[info exists sid_spawn_id]} { > catch {exec kill [exp_pid -i $sid_spawn_id]} > catch {wait -i $sid_spawn_id} > unset sid_spawn_id > sleep 4 > } > } > > proc gdb_exit {} { > set result [default_gdb_exit] > sid_exit > return $result > } > > # > # gdb_target_sid > # Set gdb to target the simulator > # > proc send_target_sid { } { > # wait a little while, giving sid time to shut down & restart its > # gdb socket > sleep 4 > send_gdb "target [target_info gdb_protocol] [target_info netport]\n" > } > > proc gdb_target_sid { } { > global gdb_prompt > global exit_status > > send_target_sid > > global timeout > set prev_timeout $timeout > set timeout 60 > verbose "Timeout is now $timeout seconds" 2 > gdb_expect { > -re "Remote debugging using.*$gdb_prompt" { > verbose "Set target to sid" > } > timeout { > perror "Couldn't set target for remote simulator." > cleanup > exit $exit_status > } > } > set timeout $prev_timeout > verbose "Timeout is now $timeout seconds" 2 > } > > # > # gdb_load -- load a file into the debugger. > # return a -1 if anything goes wrong. > # > proc gdb_load { arg } { > global verbose > global loadpath > global loadfile > global GDB > global gdb_prompt > > gdb_unload > if [gdb_file_cmd $arg] then { return -1 } > gdb_target_sid > > send_gdb "load\n" > global timeout > set prev_timeout $timeout > set timeout 2400 > verbose "Timeout is now $timeout seconds" 2 > gdb_expect { > -re ".*$gdb_prompt $" { > if $verbose>1 then { > send_user "Loaded $arg into $GDB\n" > } > set timeout 30 > verbose "Timeout is now $timeout seconds" 2 > return 1 > } > -re "$gdb_prompt $" { > if $verbose>1 then { > perror "GDB couldn't load." > } > } > timeout { > if $verbose>1 then { > perror "Timed out trying to load $arg." > } > } > } > set timeout $prev_timeout > } -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 From fnasser@cygnus.com Tue Jan 16 09:27:00 2001 From: Fernando Nasser <fnasser@cygnus.com> To: Michael Snyder <msnyder@redhat.com> Cc: gdb-patches@sources.redhat.com Subject: Re: [Fwd: RFA: [infrun.c] Fix to "nexti".] Date: Tue, 16 Jan 2001 09:27:00 -0000 Message-id: <3A648467.8B949E89@cygnus.com> References: <3A634581.9C1C76CD@redhat.com> X-SW-Source: 2001-01/msg00137.html Content-length: 2278 Michael Snyder wrote: > > Christopher Faylor wrote: > > > > On Mon, Jan 15, 2001 at 10:35:27AM -0500, Fernando Nasser wrote: > > >If there is a maintainer for this code please speak up. > > > > > >Otherwise I will check this in under the "obvious fix" rule. > > > > Do we really have an "obvious fix" rule? It seems that there is > > some confusion on this issue. > > We do (I think), but when you're discussing infrun.c, I'm not > sure that any change can be regarded as "obviously correct". > At least not in the wait_for_inferior/handle_event area. > Well, someone must be able to evaluate it and make a decision. This thing has no specific maintainer (I could not find in the MAINTAINERS file) and people keep avoiding it. But it is broken and has to be fixed. What are we going to to about it? Or will we add in the Users manual that a "nexti" command should not be used inside a function prologue or it will work as a "continue"? > By eyeball, this change looks correct to me, or at least > "not obviously incorrect". I would like to see it tested, > and perhaps the best way to do that is to apply it and then > notice if there's a sudden uptick in testsuite failures. > Well, of course I run the testsuite on it on a couple of targets and with a couple of versions of gcc. This means little with this code as it is used by all targets but what else can I do? When the code that was originally there was removed years ago and replaced with a very simplified test, all the knowledge that was accumulated over the years about different situations that can arise was lost. All that we can do know is to start accumulating that knowledge again by adding the appropriate tests for the cases where it fails. But if the bug fixes are just ignored and remain as a lost message in the list archives we will never evolve from where we are now. We could have a page with known bugs and patches that fix them, with some mechanism for feedback. But at the moment, all we can do is to install the fix and see if there is some hidden condition that was not accounted for and either revert it or refine it further. -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 From msnyder@cygnus.com Tue Jan 16 09:36:00 2001 From: Michael Snyder <msnyder@cygnus.com> To: gdb-patches@sources.redhat.com Subject: [PATCH] Fix typo in comment. Date: Tue, 16 Jan 2001 09:36:00 -0000 Message-id: <200101161736.JAA18782@cleaver.cygnus.com> X-SW-Source: 2001-01/msg00138.html Content-length: 1324 2001-01-16 Michael Snyder <msnyder@cleaver.cygnus.com> * source.c (openp): Fix typo in comment. Index: source.c =================================================================== RCS file: /cvs/src/src/gdb/source.c,v retrieving revision 1.6 diff -c -3 -p -r1.6 source.c *** source.c 2000/12/15 01:01:49 1.6 --- source.c 2001/01/16 17:34:51 *************** source_info (char *ignore, int from_tty) *** 500,506 **** so that "exec-file ./foo" or "symbol-file ./foo" insures that you get that particular version of foo or an error message). ! If FILENAMED_OPENED is non-null, set it to a newly allocated string naming the actual file opened (this string will always start with a "/". We have to take special pains to avoid doubling the "/" between the directory and the file, sigh! Emacs gets confuzzed by this when we print the --- 500,506 ---- so that "exec-file ./foo" or "symbol-file ./foo" insures that you get that particular version of foo or an error message). ! If FILENAME_OPENED is non-null, set it to a newly allocated string naming the actual file opened (this string will always start with a "/". We have to take special pains to avoid doubling the "/" between the directory and the file, sigh! Emacs gets confuzzed by this when we print the From msnyder@cygnus.com Tue Jan 16 09:41:00 2001 From: Michael Snyder <msnyder@cygnus.com> To: gdb-patches@sources.redhat.com Subject: [PATCH]: minor fix to procfs_stopped_by_watchpoint Date: Tue, 16 Jan 2001 09:41:00 -0000 Message-id: <200101161741.JAA18804@cleaver.cygnus.com> X-SW-Source: 2001-01/msg00139.html Content-length: 1054 2001-01-16 Michael Snyder <msnyder@cleaver.cygnus.com> * procfs.c (procfs_stopped_by_watchpoint): Don't die if process goes away -- just return false (ie. not stopped by watchpoint). Index: procfs.c =================================================================== RCS file: /cvs/src/src/gdb/procfs.c,v retrieving revision 1.21 diff -c -3 -p -r1.21 procfs.c *** procfs.c 2000/12/15 01:01:48 1.21 --- procfs.c 2001/01/16 17:39:47 *************** procfs_stopped_by_watchpoint (int pid) *** 4793,4800 **** { procinfo *pi; ! pi = find_procinfo_or_die (pid == -1 ? ! PIDGET (inferior_pid) : PIDGET (pid), 0); if (proc_flags (pi) & (PR_STOPPED | PR_ISTOP)) { if (proc_why (pi) == PR_FAULTED) --- 4793,4804 ---- { procinfo *pi; ! pi = find_procinfo (pid == -1 ? ! PIDGET (inferior_pid) : PIDGET (pid), 0); ! ! if (!pi) /* If no process, then not stopped by watchpoint! */ ! return 0; ! if (proc_flags (pi) & (PR_STOPPED | PR_ISTOP)) { if (proc_why (pi) == PR_FAULTED) From nsd@redhat.com Tue Jan 16 12:17:00 2001 From: Nick Duffek <nsd@redhat.com> To: ac131313@cygnus.com Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] New register definition interface Date: Tue, 16 Jan 2001 12:17:00 -0000 Message-id: <200101162018.PAA27643@nog.bosbc.com> References: <3A63C202.F418E4ED@cygnus.com> X-SW-Source: 2001-01/msg00140.html Content-length: 1564 On 16-Jan-2001, Andrew Cagney wrote: >4. Add a function like: > > set_gdbarch_data (struct gdbarch *gdbarch, > struct gdbarch_data *handle, > void *value); [...] > gdbarch calls ..._gdbarch_init() > -> calls your_module's_init_or_setup_or_something() > -> calls set_gdbarch_data (gdbarch, your_modules_handle, >your_modules_data); > -> calls set_various_other_methods (...); That looks good to me. It's very similar to what regs.c does, except that it calls set_gdbarch_register_list() instead of set_gdbarch_data(). Specifically: 1. <arch>_gdbarch_init() in <arch>-tdep.c calls regs_init_finish(). 2. regs_init_finish() calls set_gdbarch_register_list(). 3. regs_init_finish() also calls set_gdbarch_num_regs() and various other set_gdbarch_*() functions. For regs.c, I really need to do the above or something similar, because the information collected between regs_init_start(<gdbarch>) and regs_init_finish() must be attached to <gdbarch>. For cli-regs.c, I can use register_gdbarch_data() if I'm willing to waste memory. I can deal with the memory waste by: 1. ignoring it; 2. using regs.c's approach with e.g. CLIREGS_INTERNAL instead of REGISTER_LIST; 3. implementing set_gdbarch_data(). I'd prefer 2 or 3. Do you have a preference? >However, a hack of yes/no ``register_module_installed_p'' flag might be >useful so that the default case (regcache) knows to not install its >self. Since we're talking hacks, I think I might as well use REGISTER_LIST rather than adding a new REGISTER_MODULE_INSTALLED_P method. Nick From ac131313@cygnus.com Tue Jan 16 14:33:00 2001 From: Andrew Cagney <ac131313@cygnus.com> To: Nick Duffek <nsd@redhat.com> Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] New register definition interface Date: Tue, 16 Jan 2001 14:33:00 -0000 Message-id: <3A64CBAE.D480ADB7@cygnus.com> References: <3A63C202.F418E4ED@cygnus.com> <200101162018.PAA27643@nog.bosbc.com> X-SW-Source: 2001-01/msg00141.html Content-length: 1164 Nick Duffek wrote: > > On 16-Jan-2001, Andrew Cagney wrote: > > >4. Add a function like: > > > > set_gdbarch_data (struct gdbarch *gdbarch, > > struct gdbarch_data *handle, > > void *value); > [...] > > gdbarch calls ..._gdbarch_init() > > -> calls your_module's_init_or_setup_or_something() > > -> calls set_gdbarch_data (gdbarch, your_modules_handle, > >your_modules_data); > > -> calls set_various_other_methods (...); > > That looks good to me. It's very similar to what regs.c does, except that > it calls set_gdbarch_register_list() instead of set_gdbarch_data(). The difference is that the data is kept private to the regs.c file (those interfaces again). It isn't possible for external code to go grubbing around in internals when you're not looking. > Since we're talking hacks, I think I might as well use REGISTER_LIST > rather than adding a new REGISTER_MODULE_INSTALLED_P method. The nice thing about REGISTER_MODULE_INSTALLED_P() is that it is so informative that the caller can conclude nothing about the actual module. This is a good thing :-) Andrew From jtc@redback.com Tue Jan 16 14:59:00 2001 From: jtc@redback.com (J.T. Conklin) To: Fernando Nasser <fnasser@redhat.com> Cc: matthew green <mrg@cygnus.com>, gdb-patches@sources.redhat.com Subject: Re: patch for compiles that don't define "unix" Date: Tue, 16 Jan 2001 14:59:00 -0000 Message-id: <5mvgrf6r3a.fsf@jtc.redback.com> References: <22097.979473536@cygnus.com> <3A61CF62.34A9FFE2@redhat.com> X-SW-Source: 2001-01/msg00142.html Content-length: 1814 >>>>> "Fernando" == Fernando Nasser <fnasser@redhat.com> writes: Fernando> This is not the proper fix though. The rdi-share Fernando> subdirectory is supposed to contain code shared with ARM, so Fernando> we shouldn't make local modifications in there (unless Fernando> absolutely necessary). Doesn't "sharing" imply something more than just importing third party code? There should be a mechanism where we can at least advocate that a change be made to shared source. I note that there are a lot of __CYGWIN32__ conditionals. How did they get into rdi-share? Unfortunately there is no documentation within rdi- share that says how to obtain the master copy so I can compare, but it ultimately doesn't matter. Either there is a mechanism to get these changes incorporated, or the rule about making local changes is flexible. Fernando> In this case we are better off with a more general fix that Fernando> will solve all possible occurrences of the lack of "unix" Fernando> problem. While mrg came up with an alternate patch, I'm not convinced it's better than his original. The original patch made defined __unix if either "unix" or "__unix__" is defined. IMO, this makes a lot more sense than the alternate solution where __unix is defined if unix is defined in host.h, but __unix is defined if __unix__ is defined via autoconf & makefiles. But if you take a look at how __unix is used, you'll see that it is used to determine whether the host is a "fairly recent" UN*X-ish host. It's used to determine whether to use sigaction() or signal(), whether the host has gettimeofday(), etc. IMO, these are should be replaced by specific feature tests. I suspect that a lot of older UN*X systems that define unix will not build rdi-share sources as is. --jtc -- J.T. Conklin RedBack Networks From msnyder@redhat.com Tue Jan 16 15:02:00 2001 From: Michael Snyder <msnyder@redhat.com> To: jtc@redback.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: patch to split embedded and linux sh targets Date: Tue, 16 Jan 2001 15:02:00 -0000 Message-id: <3A64D310.6A39F1D7@redhat.com> References: <5mzogss0zd.fsf@jtc.redback.com> X-SW-Source: 2001-01/msg00143.html Content-length: 3504 JT, What exactly is broken? What are you fixing? As far as I know, "sh-elf" builds, and so does "sh-linux-elf". "J.T. Conklin" wrote: > > I submit the enclosed patch for a approval. The current sh target, > which was once a embedded only target has been made gnu/linux-specific > by the inclusion of shared library support. > > This patch creates a embedded target (sh-*-coff*, sh-*-elf*) by moving > the linux bits to its own configuration (sh-*-linux*). I haven't > changed the linux config other than by renaming sh.mt to linux.mt, > although I believe that support for the SH3 ROM monitor, the e7000 > ICE, and perhaps the SH simulator can be removed. > > --jtc > > 2001-01-15 J.T. Conklin <jtc@redback.com> > > * configure/sh/embed.mt: New file. > * configure/sh/linux.mt: New file. > * configure/sh/sh.mt: Removed. > * configure.tgt (sh-*-coff*, sh-*-elf*, sh-*-linux): New targets. > (sh-*-*): Removed. > > Index: configure.tgt > =================================================================== > RCS file: /cvs/src/src/gdb/configure.tgt,v > retrieving revision 1.16 > diff -c -r1.16 configure.tgt > *** configure.tgt 2000/12/14 20:15:45 1.16 > --- configure.tgt 2001/01/16 02:01:57 > *************** > *** 263,269 **** > rs6000-*-*) gdb_target=rs6000 ;; > > sh*-*-pe) gdb_target=wince ;; > ! sh-*-*) gdb_target=sh ;; > > sparc-*-aout*) gdb_target=sparc-em ;; > sparc-*-coff*) gdb_target=sparc-em ;; > --- 263,271 ---- > rs6000-*-*) gdb_target=rs6000 ;; > > sh*-*-pe) gdb_target=wince ;; > ! sh-*-coff*) gdb_target=embed ;; > ! sh-*-elf*) gdb_target=embed ;; > ! sh-*-linux*) gdb_target=linux ;; > > sparc-*-aout*) gdb_target=sparc-em ;; > sparc-*-coff*) gdb_target=sparc-em ;; > Index: config/sh/embed.mt > =================================================================== > RCS file: embed.mt > diff -N embed.mt > *** /dev/null Tue May 5 13:32:27 1998 > --- embed.mt Mon Jan 15 18:01:57 2001 > *************** > *** 0 **** > --- 1,6 ---- > + # Target: Embedded Hitachi Super-H with ICE and simulator > + TDEPFILES= sh-tdep.o monitor.o sh3-rom.o remote-e7000.o ser-e7kpc.o dsrec.o > + TM_FILE= tm-sh.h > + > + SIM_OBS = remote-sim.o > + SIM = ../sim/sh/libsim.a > Index: config/sh/linux.mt > =================================================================== > RCS file: linux.mt > diff -N linux.mt > *** /dev/null Tue May 5 13:32:27 1998 > --- linux.mt Mon Jan 15 18:01:57 2001 > *************** > *** 0 **** > --- 1,6 ---- > + # Target: Hitachi Super-H running GNU/Linux > + TDEPFILES= sh-tdep.o monitor.o sh3-rom.o remote-e7000.o ser-e7kpc.o dsrec.o solib.o solib-svr4.o > + TM_FILE= tm-linux.h > + > + SIM_OBS = remote-sim.o > + SIM = ../sim/sh/libsim.a > Index: config/sh/sh.mt > =================================================================== > RCS file: sh.mt > diff -N sh.mt > *** /sourceware/cvs-tmp/cvsiq6IWP Mon Jan 15 18:01:58 2001 > --- /dev/null Tue May 5 13:32:27 1998 > *************** > *** 1,6 **** > - # Target: Hitachi Super-H with ICE and simulator > - TDEPFILES= sh-tdep.o monitor.o sh3-rom.o remote-e7000.o ser-e7kpc.o dsrec.o solib.o solib-svr4.o > - TM_FILE= tm-linux.h > - > - SIM_OBS = remote-sim.o > - SIM = ../sim/sh/libsim.a > --- 0 ---- > > -- > J.T. Conklin > RedBack Networks From bje@redhat.com Tue Jan 16 15:02:00 2001 From: Ben Elliston <bje@redhat.com> To: Fernando Nasser <fnasser@cygnus.com> Cc: <gdb-patches@sources.redhat.com> Subject: Re: [testsuite] Contribution to testsuite/config Date: Tue, 16 Jan 2001 15:02:00 -0000 Message-id: <Pine.LNX.4.31.0101170948510.26663-100000@moshpit.cygnus.com> References: <3A647D4B.4B343299@cygnus.com> X-SW-Source: 2001-01/msg00144.html Content-length: 44 Sure thanks. Commited. Thanks, Ben ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <200101121935.LAA03678@scv2.apple.com>]
* Re: [patch] fix for infinite recursion in lookup_symbol [not found] <200101121935.LAA03678@scv2.apple.com> @ 2001-01-12 12:13 ` Fernando Nasser 2001-01-17 13:09 ` Elena Zannoni 1 sibling, 0 replies; 6+ messages in thread From: Fernando Nasser @ 2001-01-12 12:13 UTC (permalink / raw) To: Jim Ingham; +Cc: gdb-patches, insight Jim, You saved my life! This causes Insight to crash. One case I saw is that there were C++ methods starting with "main", so the look for main to show in the Source Window would cause a memory exhaust situation. The other case is when a the Variable Balloons try to show some overloaded symbol and it also goes into loop. TO THE INSIGHT LIST FOLKS WHO WERE HAVING THOSE PROBLEMS: Can you please try Jim's patch and let us know if it fixed your problems? Thanks. Fernando Jim Ingham wrote: > > Hi, all, > > The following patch fixes an infinite recursion in the variable lookup > code for C++ objects that are specified in mangled form. The old code > would take the mangled name into lookup_symbol, unmangle it, and then in > this bit pass the mangled name BACK to lookup_symbol, which would > unmangle it and come right back here... Not a good thing. The bug > crept in when lookup_symbol was broken up into lookup_symbol and > lookup_symbol_aux, the correction is clearly what was meant. > > 2001-01-09 James Ingham <jingham@inghji.apple.com> > > * symtab.c (lookup_symbol_aux): Call lookup_symbol_aux to > lookup a > mangled symbol rather than recursing into lookup_symbol, since > this > will just re-unmangle the name & call lookup_symbol_aux - > leading to > an infinite recursion. > > Index: symtab.c > =================================================================== > RCS file: /cvs/src/src/gdb/symtab.c,v > retrieving revision 1.15 > diff -c -w -r1.15 symtab.c > *** symtab.c 2000/09/04 08:29:25 1.15 > --- symtab.c 2001/01/12 19:29:21 > *************** > *** 754,760 **** > { > /* This is a mangled variable, look it up by its > mangled name. */ > ! return lookup_symbol (SYMBOL_NAME (msymbol), block, > namespace, is_a_field_of_this, > symtab); > } > /* There are no debug symbols for this file, or we are looking > --- 754,760 ---- > { > /* This is a mangled variable, look it up by its > mangled name. */ > ! return lookup_symbol_aux (SYMBOL_NAME (msymbol), block, > namespace, is_a_field_of_this, > symtab); > } > /* There are no debug symbols for this file, or we are looking -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 From nsd@redhat.com Fri Jan 12 12:43:00 2001 From: Nick Duffek <nsd@redhat.com> To: ac131313@cygnus.com Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] spelling corrections Date: Fri, 12 Jan 2001 12:43:00 -0000 Message-id: <200101122051.f0CKpYT04311@rtl.cygnus.com> References: <3A5ED35A.B41E9304@cygnus.com> X-SW-Source: 2001-01/msg00094.html Content-length: 70 On 12-Jan-2001, Andrew Cagney wrote: >yes. Thanks, committed. Nick From nsd@redhat.com Fri Jan 12 12:48:00 2001 From: Nick Duffek <nsd@redhat.com> To: ac131313@cygnus.com Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] gdbarch.sh: multi-arch PARM_BOUNDARY Date: Fri, 12 Jan 2001 12:48:00 -0000 Message-id: <200101122055.f0CKtkD04372@rtl.cygnus.com> References: <3A5EF5A4.7C7EF047@cygnus.com> X-SW-Source: 2001-01/msg00095.html Content-length: 299 On 12-Jan-2001, Andrew Cagney wrote: >This is a new architecture method. No, it's an existing method, I'm just multi-arching it. >Can you explain its intended purpose. From gdbint.texinfo: If non-zero, round arguments to a boundary of this many bits before pushing them on the stack. Nick From nsd@redhat.com Fri Jan 12 13:32:00 2001 From: Nick Duffek <nsd@redhat.com> To: ac131313@cygnus.com Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] new BASEREG_ADDRESS macro Date: Fri, 12 Jan 2001 13:32:00 -0000 Message-id: <200101122140.f0CLeYF04411@rtl.cygnus.com> References: <3A5EF913.DD51B9E2@cygnus.com> X-SW-Source: 2001-01/msg00096.html Content-length: 370 On 12-Jan-2001, Andrew Cagney wrote: >Can you think of a name other than BASEREG_ADDRESS() that better reflects >the transformation being performed? >my first guess was that BASEREG_ADDRESS returns the address of the >register BASE in, at or near ``addr''. Yes, I can see how one might think that. How about ADJUST_BASEREG_ADDRESS? Other suggestions welcome. Nick From nsd@redhat.com Fri Jan 12 13:36:00 2001 From: Nick Duffek <nsd@redhat.com> To: ac131313@cygnus.com Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] New register definition interface Date: Fri, 12 Jan 2001 13:36:00 -0000 Message-id: <200101122144.f0CLi0104421@rtl.cygnus.com> References: <3A5F09B3.93555F06@cygnus.com> X-SW-Source: 2001-01/msg00097.html Content-length: 399 On 12-Jan-2001, Andrew Cagney wrote: >At a guess the cli/* change is independant of the file reg.c. It depends on regs.c, but not vice versa. So yes, it could have been a separate add-on patch. >Assuming it is it should go in per fixes from Fernando and (private) >notes from me. As Fernando said, he's approved it, but I'd be interested in hearing whatever additional comments you have. Nick From jingham@apple.com Fri Jan 12 14:03:00 2001 From: Jim Ingham <jingham@apple.com> To: Daniel Berlin <dberlin@redhat.com> Cc: gdb-patches@sources.redhat.com Subject: Re: [patch] fix for infinite recursion in lookup_symbol Date: Fri, 12 Jan 2001 14:03:00 -0000 Message-id: <200101122203.OAA20207@scv1.apple.com> References: <Pine.LNX.4.10.10101121507570.8389-100000@www.cgsoftware.com> X-SW-Source: 2001-01/msg00098.html Content-length: 1351 Daniel, Well, while you are waiting, it might be nice to check in fixes for some of these, since they are pretty simple fixes, and the bugs are pretty annoying (in this case it causes gdb to crash, and people tend to REALLY hate it when their debugger crashes). It wasted a couple of days of my time chasing it down, and apparently a couple of days of Fernando's time as well. Jim On Friday, January 12, 2001, at 12:10 PM, Daniel Berlin wrote: > > > On Fri, 12 Jan 2001, Jim Ingham wrote: > >> Hi, all, >> >> The following patch fixes an infinite recursion in the variable lookup >> code for C++ objects that are specified in mangled form. The old code >> would take the mangled name into lookup_symbol, unmangle it, and then >> in >> this bit pass the mangled name BACK to lookup_symbol, which would >> unmangle it and come right back here... Not a good thing. The bug >> crept in when lookup_symbol was broken up into lookup_symbol and >> lookup_symbol_aux, the correction is clearly what was meant. > > This was already known, and we are still waiting for Jim Blandy to > make a > decision whether we should revert the binary searching symbol lookup for > C++ stuff or not. > If we decide to stay with the non-linear symbol lookup, i'll fix the > bugs, > as i already have patches for most of them (there aren't many). > > --Dan > From dberlin@redhat.com Fri Jan 12 17:52:00 2001 From: Daniel Berlin <dberlin@redhat.com> To: Jim Ingham <jingham@apple.com> Cc: Daniel Berlin <dberlin@redhat.com>, <gdb-patches@sources.redhat.com> Subject: Re: [patch] fix for infinite recursion in lookup_symbol Date: Fri, 12 Jan 2001 17:52:00 -0000 Message-id: <Pine.LNX.4.31.0101122049230.14785-100000@www.cgsoftware.com> References: <200101122203.OAA20207@scv1.apple.com> X-SW-Source: 2001-01/msg00099.html Content-length: 873 On Fri, 12 Jan 2001, Jim Ingham wrote: > Daniel, > > Well, while you are waiting, it might be nice to check in fixes for some > of these, since they are pretty simple fixes, and the bugs are pretty > annoying (in this case it causes gdb to crash, and people tend to REALLY > hate it when their debugger crashes). I can't without approval from Jim anyway. I'm still waiting for approval for some simple changes I submitted a few weeks ago to be approved as well, i don't want to juggle that many outstanding patches. > It wasted a couple of days of my > time chasing it down, and apparently a couple of days of Fernando's time > as well. Sorry to hear that. If you look back, ti was reported in either november or december, and a huge discussion ensued. Wish there was something more I could do, but it's not my area of maintenance, so all I can do is submit patches. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch] fix for infinite recursion in lookup_symbol [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> 1 sibling, 1 reply; 6+ messages in thread From: Elena Zannoni @ 2001-01-17 13:09 UTC (permalink / raw) To: Jim Ingham, fnasser; +Cc: gdb-patches 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 :-). Thanks Elena Jim Ingham writes: > Hi, all, > > The following patch fixes an infinite recursion in the variable lookup > code for C++ objects that are specified in mangled form. The old code > would take the mangled name into lookup_symbol, unmangle it, and then in > this bit pass the mangled name BACK to lookup_symbol, which would > unmangle it and come right back here... Not a good thing. The bug > crept in when lookup_symbol was broken up into lookup_symbol and > lookup_symbol_aux, the correction is clearly what was meant. > > 2001-01-09 James Ingham <jingham@inghji.apple.com> > > * symtab.c (lookup_symbol_aux): Call lookup_symbol_aux to > lookup a > mangled symbol rather than recursing into lookup_symbol, since > this > will just re-unmangle the name & call lookup_symbol_aux - > leading to > an infinite recursion. > > > Index: symtab.c > =================================================================== > RCS file: /cvs/src/src/gdb/symtab.c,v > retrieving revision 1.15 > diff -c -w -r1.15 symtab.c > *** symtab.c 2000/09/04 08:29:25 1.15 > --- symtab.c 2001/01/12 19:29:21 > *************** > *** 754,760 **** > { > /* This is a mangled variable, look it up by its > mangled name. */ > ! return lookup_symbol (SYMBOL_NAME (msymbol), block, > namespace, is_a_field_of_this, > symtab); > } > /* There are no debug symbols for this file, or we are looking > --- 754,760 ---- > { > /* This is a mangled variable, look it up by its > mangled name. */ > ! return lookup_symbol_aux (SYMBOL_NAME (msymbol), block, > namespace, is_a_field_of_this, > symtab); > } > /* There are no debug symbols for this file, or we are looking > From cgf@redhat.com Wed Jan 17 13:12:00 2001 From: Christopher Faylor <cgf@redhat.com> To: gdb-patches@sources.redhat.com Subject: Re: [patch] fix for infinite recursion in lookup_symbol Date: Wed, 17 Jan 2001 13:12:00 -0000 Message-id: <20010117161229.B15404@redhat.com> References: <200101121935.LAA03678@scv2.apple.com> <14950.2567.654425.826984@kwikemart.cygnus.com> X-SW-Source: 2001-01/msg00158.html Content-length: 754 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. 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 From nsd@redhat.com Wed Jan 17 13:17:00 2001 From: Nick Duffek <nsd@redhat.com> To: ac131313@cygnus.com Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] New register definition interface Date: Wed, 17 Jan 2001 13:17:00 -0000 Message-id: <200101172125.f0HLPDs01986@rtl.cygnus.com> References: <3A64CBAE.D480ADB7@cygnus.com> X-SW-Source: 2001-01/msg00159.html Content-length: 1086 On 17-Jan-2001, Andrew Cagney wrote: >> That looks good to me. It's very similar to what regs.c does, except that >> it calls set_gdbarch_register_list() instead of set_gdbarch_data(). >The difference is that the data is kept private to the regs.c file >(those interfaces again). It isn't possible for external code to go >grubbing around in internals when you're not looking. Yes. I wrote: >I can deal with the memory waste by: > > 1. ignoring it; > 2. using regs.c's approach with e.g. CLIREGS_INTERNAL instead of > REGISTER_LIST; > 3. implementing set_gdbarch_data(). > >I'd prefer 2 or 3. Do you have a preference? If I understand correctly, you're expressing a preference for 3. I'll look into implementing that. On 17-Jan-2001, Andrew Cagney wrote: >The nice thing about REGISTER_MODULE_INSTALLED_P() is that it is so >informative that the caller can conclude nothing about the actual >module. This is a good thing :-) I don't understand whether that means "regcache.c is active" or "regs.c is active". I'd rather use REGCACHE_MODULE_ACTIVE_P(), okay? Nick From dberlin@redhat.com Wed Jan 17 13:28:00 2001 From: Daniel Berlin <dberlin@redhat.com> To: 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 13:28:00 -0000 Message-id: <8890000.979766696@dynamic-addr-83-177.resnet.rochester.edu> References: <20010117161229.B15404@redhat.com> X-SW-Source: 2001-01/msg00160.html Content-length: 1162 --On Wednesday, January 17, 2001 16:12:29 -0500 Christopher Faylor <cgf@redhat.com> 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. > > 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 like this idea. after all, patches can always be reverted or backed out if necessary. It's unlikely this will happen anyway, since maintainers generally got to be maintainers from submitting good patches, and having expertise in GDB (except me, I slept my way there). --Dan ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <20010117161229.B15404@redhat.com>]
* Re: [patch] fix for infinite recursion in lookup_symbol [not found] ` <20010117161229.B15404@redhat.com> @ 2001-01-17 13:55 ` Fernando Nasser 0 siblings, 0 replies; 6+ messages in thread From: Fernando Nasser @ 2001-01-17 13:55 UTC (permalink / raw) To: Christopher Faylor; +Cc: gdb-patches 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2001-01-19 8:25 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <200101172157.QAA21576@texas.cygnus.com>
[not found] ` <14950.6503.362049.921003@kwikemart.cygnus.com>
2001-01-18 15:35 ` [patch] fix for infinite recursion in lookup_symbol Jim Blandy
[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] <B6889200.268C%jingham@apple.com>
2001-01-15 12:14 ` Fernando Nasser
[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 is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox