From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Faylor To: Eli Zaretskii Cc: sjohnson@neurizon.net, fnasser@cygnus.com, gdb-patches@sources.redhat.com Subject: Re: [patch] fix for infinite recursion in lookup_symbol Date: Fri, 19 Jan 2001 08:25:00 -0000 Message-id: <20010119112428.B6553@redhat.com> References: <3A677652.FA74EAD0@neurizon.net> <6480-Fri19Jan2001122012+0200-eliz@is.elta.co.il> X-SW-Source: 2001-01/msg00197.html 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 >> >> 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 To: Andrew Cagney Cc: matthew green , Fernando Nasser , 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 > > > > * 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 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 >>> >>> 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" 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 > > 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 To: rearnsha@arm.com Cc: Nick Clifton , GDB Patches , SID Discussion 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 > > * 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 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: 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 To: , Subject: [DejaGNU patch] Re-document --mail Date: Sat, 20 Jan 2001 04:28:00 -0000 Message-id: 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 * 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