Re: [patch] fix for infinite recursion in lookup_symbol

[Chris Faylor <cgf@redhat.com>]

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