GDB 6.1 "frozen"

GDB 6.1 "frozen"

[Andrew Cagney]

I've got:

- TUI doco (which should go in tomorrow)
- this GNU/Novell PPC 64 build problem

but I think that will be resolved in the next 24 hours.

Andrew

Re: GDB 6.1 "frozen"

[David Carlton]

On Thu, 25 Mar 2004 17:48:19 -0500, Andrew Cagney <cagney@gnu.org> said:

> I've got:
> - TUI doco (which should go in tomorrow)
> - this GNU/Novell PPC 64 build problem

> but I think that will be resolved in the next 24 hours.

I thought we still had disagreements over PROBLEMS: at the very least,
we should apply the following patch or some variant thereof.

David Carlton
carlton@kealia.com

2004-03-25  David Carlton  <carlton@kealia.com>

	* PROBLEMS: Refer to gdb/1588 instead of gdb/826.

Index: PROBLEMS
===================================================================
RCS file: /cvs/src/src/gdb/PROBLEMS,v
retrieving revision 1.23.2.3
diff -u -p -r1.23.2.3 PROBLEMS
--- PROBLEMS	25 Mar 2004 21:20:26 -0000	1.23.2.3
+++ PROBLEMS	25 Mar 2004 23:48:41 -0000
@@ -15,11 +15,6 @@ the abortion is displayed only after the
 
 *** C++ support
 
-gdb/826: variables in C++ namespaces have to be enclosed in quotes
-
-When referring to a variable in C++ code that is inside a
-namespace, you have to put it inside single quotes.
-
 gdb/931: GDB could be more generous when reading types C++ templates on input
 
 When the user types a template, GDB frequently requires the type to be
@@ -43,6 +38,18 @@ type is "foobar__Fi.0:Local".
 This applies only to classes where the class type is defined inside a
 function, not to variables defined with types that are defined somewhere
 outside any function (which most types are).
+
+gdb/1588: names of c++ nested types in casts must be enclosed in quotes
+
+You must type
+  (gdb) print ('Foo::Bar') x
+or
+  (gdb) print ('Foo::Bar' *) y
+instead of
+  (gdb) print (Foo::Bar) x
+or
+  (gdb) print (Foo::Bar *) y
+respectively.
 
 gdb/1091: Constructor breakpoints ignored
 gdb/1193: g++ 3.3 creates multiple constructors: gdb 5.3 can't set breakpoints

Re: GDB 6.1 "frozen"

[Andrew Cagney]

> On Thu, 25 Mar 2004 17:48:19 -0500, Andrew Cagney <cagney@gnu.org> said:
> 
> 
>>> I've got:
>>> - TUI doco (which should go in tomorrow)
>>> - this GNU/Novell PPC 64 build problem
> 
> 
>>> but I think that will be resolved in the next 24 hours.
> 
> 
> I thought we still had disagreements over PROBLEMS: at the very least,
> we should apply the following patch or some variant thereof.
> 
> David Carlton
> carlton@kealia.com
> 
> 2004-03-25  David Carlton  <carlton@kealia.com>
> 
> 	* PROBLEMS: Refer to gdb/1588 instead of gdb/826.

Ok it's "frozen" except for doco changes such as this (and the above, 
and another entry I need to fix for frames that I forgot ...).  Anyway, Eli?

Further to that we need to apply the "proper fix" to  PROBLEMS, NEWS, 
and README, CONTRIBUTE, and TODO. i.e., get them all integrated into the 
doco.

Andrew

Re: GDB 6.1 "frozen"

[Eli Zaretskii]

> Date: Thu, 25 Mar 2004 19:14:37 -0500
> From: Andrew Cagney <cagney@gnu.org>
> > 
> > 2004-03-25  David Carlton  <carlton@kealia.com>
> > 
> > 	* PROBLEMS: Refer to gdb/1588 instead of gdb/826.
> 
> Ok it's "frozen" except for doco changes such as this (and the above, 
> and another entry I need to fix for frames that I forgot ...).  Anyway, Eli?

I have no objections to David's suggestion, except that the manual
seems to already say that C++ symbols might need quoting in some
situations, right?  However, if the people who work on C++ support
feel that this particular problem needs to be in PROBLEMS, I don't
object.

> Further to that we need to apply the "proper fix" to  PROBLEMS, NEWS, 
> and README, CONTRIBUTE, and TODO. i.e., get them all integrated into the 
> doco.

Sorry, I'm not sure I understand what needs to be done here.

Re: GDB 6.1 "frozen"

[Andrew Cagney]

>>> Further to that we need to apply the "proper fix" to  PROBLEMS, NEWS, 
>>> and README, CONTRIBUTE, and TODO. i.e., get them all integrated into the 
>>> doco.
> 
> 
> Sorry, I'm not sure I understand what needs to be done here.

Long standing todo item:  GCC has a single copy of these and a few other 
files in the doc/ directory.  The README, INSTALL, ... files are all 
generated from a single source.

GDB should investigate the same thing.  At present there is a lot of 
redundancy.

We should also throw open the question of how to best present release 
information such as our list of known to work systems, our most serious 
problems, known bugs, perhaphs even some test results (just, please not 
today and not for 6.1 :-).

Andrew

Re: GDB 6.1 "frozen"

[David Carlton]

On Fri, 26 Mar 2004 11:53:06 +0200, "Eli Zaretskii" <eliz@gnu.org> said:

>> Date: Thu, 25 Mar 2004 19:14:37 -0500
>> From: Andrew Cagney <cagney@gnu.org>
>> > 
>> > 2004-03-25  David Carlton  <carlton@kealia.com>
>> > 
>> > 	* PROBLEMS: Refer to gdb/1588 instead of gdb/826.
>> 
>> Ok it's "frozen" except for doco changes such as this (and the above, 
>> and another entry I need to fix for frames that I forgot ...).  Anyway, Eli?

> I have no objections to David's suggestion, except that the manual
> seems to already say that C++ symbols might need quoting in some
> situations, right?

I didn't see that when I just skimmed the manual, but I might have
missed it.  (I did see some other out-of-date things.  Hmm.)

> However, if the people who work on C++ support feel that this
> particular problem needs to be in PROBLEMS, I don't object.

I have mixed feelings about Michael's desire of mentioning everything
that could be called a regression, no matter how small, in PROBLEMS.
However, that's a separate argument; given that this issue is
currently referred to in PROBLEMS, we might as well at least have the
reference be accurate, while we continue our argument about the scope
of problems.

I'll apply the patch to mainline and 6.1.

David Carlton
carlton@kealia.com

Re: GDB 6.1 "frozen"

[Eli Zaretskii]

> From: David Carlton <carlton@kealia.com>
> Date: Fri, 26 Mar 2004 09:00:42 -0800
> 
> > I have no objections to David's suggestion, except that the manual
> > seems to already say that C++ symbols might need quoting in some
> > situations, right?
> 
> I didn't see that when I just skimmed the manual, but I might have
> missed it.

See the node "Completion" (and "i quotes RET" in Info would land you
there for free ;-).  However, I see that I misremembered: that part of
the manual deals with problems in completion, not with C++ symbols in
general.

> I have mixed feelings about Michael's desire of mentioning everything
> that could be called a regression, no matter how small, in PROBLEMS.

Me too.  Do you feel that this specific issue is not important enough
to be in PROBLEMS?

Re: GDB 6.1 "frozen"

[Eli Zaretskii]

> Date: Fri, 26 Mar 2004 09:17:12 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> Long standing todo item:  GCC has a single copy of these and a few other 
> files in the doc/ directory.  The README, INSTALL, ... files are all 
> generated from a single source.

Ah, that one...

Yes, I know about GCC's setup, but I cannot say that I see how it is
so immensely useful to justify any significant effort in doing
something similar in GDB.  IMO, there's nothing wrong with maintaining
a couple of text files.

Also, it is my personal opinion is that text files produced by
makeinfo look awkward, almost ugly, and therefore doing what GCC does
is only justified for large documents that need to be distributed in
Info and other formats as well as in plain text.  Like a FAQ, for
example.

So I'm not going to work on that or encourage others to do it.  But if
someone steps forward and does the job, I won't object to using it if
the results are good and generally useful.

> At present there is a lot of redundancy.

What redundancy is that?

> We should also throw open the question of how to best present release 
> information such as our list of known to work systems, our most serious 
> problems, known bugs, perhaphs even some test results (just, please not 
> today and not for 6.1 :-).

By all means, let's discuss it whenever you are ready.  It's not
urgent, so no need to start that now.

Re: GDB 6.1 "frozen"

[David Carlton]

On Fri, 26 Mar 2004 19:29:25 +0200, "Eli Zaretskii" <eliz@gnu.org> said:
>> From: David Carlton <carlton@kealia.com>
>> Date: Fri, 26 Mar 2004 09:00:42 -0800

>> I have mixed feelings about Michael's desire of mentioning
>> everything that could be called a regression, no matter how small,
>> in PROBLEMS.

> Me too.  Do you feel that this specific issue is not important
> enough to be in PROBLEMS?

Personally, I wouldn't list any of the C++ issues other than the
breakpoints in constructors bug.  Michael's reason for want to list
all regressions, if I understand him properly, is so that users can
check to see if anything has changed from 6.0 to 6.1 that would cause
them not to want to upgrade; I have a very hard time imagining a
scenario where any of the C++ issues that are listed would block an
upgrade.

So the only question, in my mind, is what issues are important enough
that users should be warned about them so we don't get lots of bug
reports; the breakpoints in constructors issue seems to me to qualify
(I get asked about that often enough at work) but the other issues
don't.

Having said that, it is the case that I occasionally get asked at work
about why people are getting errors when casting, whereas I never get
asked about problems related to gdb/931, gdb/1512, or gdb/1516.  So I
could see a case for keeping the mention of gdb/1518 in there as well.

David Carlton
carlton@kealia.com

Re: GDB 6.1 "frozen"

[Eli Zaretskii]

> From: David Carlton <carlton@kealia.com>
> Date: Fri, 26 Mar 2004 09:58:13 -0800
> 
> Michael's reason for want to list
> all regressions, if I understand him properly, is so that users can
> check to see if anything has changed from 6.0 to 6.1 that would cause
> them not to want to upgrade; I have a very hard time imagining a
> scenario where any of the C++ issues that are listed would block an
> upgrade.

I tend to agree.  I understand that the C++ support in 6.1 got much
better, and that the number of resolved problem outnumbers the new
ones.

Michael, could you please comment?

> So the only question, in my mind, is what issues are important enough
> that users should be warned about them so we don't get lots of bug
> reports; the breakpoints in constructors issue seems to me to qualify
> (I get asked about that often enough at work) but the other issues
> don't.

Yes, I think this is the principle that should govern our decisions
what to include in PROBLEMS.

> Having said that, it is the case that I occasionally get asked at work
> about why people are getting errors when casting, whereas I never get
> asked about problems related to gdb/931, gdb/1512, or gdb/1516.  So I
> could see a case for keeping the mention of gdb/1518 in there as well.

To me, the text you suggested sounds important enough to be added.