Re: [patch/rfc] Add meaningful section titles to PROBLEMS

Re: [patch/rfc] Add meaningful section titles to PROBLEMS

[Michael Elizabeth Chastain]

mec> I'm willing to abide by whatever Eli, the maintainer, decides.
ac> I don't know who the maintainer is, however doco and releng should be 
ac> "on the same page".

Well, then I think you need to decide who the maintainer of PROBLEMS
is and document that in the MAINTAINERS file.  There are no specific
entries for "releng" so I presumed they fell under documentation.

ac> As I stated in my cover note, gdb/1560 for instance is a regression 
ac> since GDB _5.0_.

Okay, then a user of gdb 6.0 is not going to suffer from additional
hurt from gdb/1560 if they upgrade to gdb 6.1.  And you are right, it's
not a regression from 6.0.

ac> Trying to list regressions is of little value.

We have different opinions on this.

When I upgrade a software package, I find the list of regressions from
my current version to be of *great* value.  For each new problem, I have
to ascertain whether it affects my system.  If it affects my system, I
have to figure out how to work around the problem.  If the problems are
too severe, then I know that I am better off not upgrading.

ac> Giving this file meaningful titles (so users don't have to wade through
ac> irrelevances such as gdb/1512) is a first step.

gdb/1512 is a bug in gdb.  Naturally, we can describe it so that most
people will realize that it won't bother them and can just read through
to the next bug.

If you claim that gdb/1512 is irrelevant to every user (and I'm almost
of that opinion myself), and you can persuade other maintainers of that
position, then we can stop testing for it and just PASS those tests.
But right now we consider that behavior of gdb to be a bug that needs
fixing.

Michael C

Re: [patch/rfc] Add meaningful section titles to PROBLEMS

[Eli Zaretskii]

> Date: Fri, 19 Mar 2004 12:45:17 -0500 (EST)
> From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
> 
> When I upgrade a software package, I find the list of regressions from
> my current version to be of *great* value.  For each new problem, I have
> to ascertain whether it affects my system.  If it affects my system, I
> have to figure out how to work around the problem.  If the problems are
> too severe, then I know that I am better off not upgrading.

I don't think regressions since version X.Y is something we need to
mention in PROBLEMS.  It is an implicit assumption of users that when
they upgrade to a higher version, they have _less_ bugs, not more.  If
some unfortunate release violates this principle to a high degree, we
should immediately make a bugfix release.

So I think known user-level bugs need to be mentioned, but it's not
very important to say in which release they appeared first.

Re: [patch/rfc] Add meaningful section titles to PROBLEMS

[Andrew Cagney]

>>Date: Fri, 19 Mar 2004 11:16:35 -0500
>>> From: Andrew Cagney <cagney@gnu.org>
>>> 
>>> This patch gets rid of the meaningless(1) "Regressions since X.X" titles
>>> replacing them with functional section titles:
>>> 
>>> *** C++ support
>>> 
>>> *** Stack backtraces
>>> 
>>> *** Misc
>>> 
>>> (I think that's all)  The file is re-ordered but none of the contents
>>> change.
>>> 
>>> comments?
> 
> 
> Fine with me.

I've checked this in trunk/6.1.  I'll make certain that we revisit this 
later.

Andrew

Re: [patch/rfc] Add meaningful section titles to PROBLEMS

[Eli Zaretskii]

> Date: Fri, 19 Mar 2004 11:16:35 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> This patch gets rid of the meaningless(1) "Regressions since X.X" titles
> replacing them with functional section titles:
> 
> *** C++ support
> 
> *** Stack backtraces
> 
> *** Misc
> 
> (I think that's all)  The file is re-ordered but none of the contents
> change.
> 
> comments?

Fine with me.

> In terms of content, I think any "problem" that is there for more than
> one full release cycle should be documented

Why not document them when we cut the release branch, if we decide
that this particular problem is not going to be fixed in that release?
Why wait for another release?

Re: [patch/rfc] Add meaningful section titles to PROBLEMS

[Eli Zaretskii]

> From: David Carlton <carlton@kealia.com>
> Date: Fri, 19 Mar 2004 09:43:48 -0800
> 
> > As for some of the others, I think they would be better served as
> > notes in the documentation (i.e., gdb.texinfo).
> 
> That's a good point - if we want to make users aware of certain
> well-known bugs, then gdb.texinfo is a much more visible place than
> PROBLEMS.

I disagree: we should certainly NOT document our bugs in the manual.

> (Nobody will see PROBLEMS other than possibly the specific
> individual, if any, who is installing that version of GDB by hand.)
> GCC has a section of known bugs in its manual; we should follow suit.

Why not follow suit of Emacs (which does have PROBLEMS, but not a
section about known bugs in the manual).

Note that PROBLEMS might mention problems that are actually bugs in
other related software, not necessarily in GDB per se.  Are we going
to document them in the manual as well?  I don't think so.

Re: [patch/rfc] Add meaningful section titles to PROBLEMS

[Eli Zaretskii]

> Date: Fri, 19 Mar 2004 14:59:20 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> I've attached the original PROBLEMS file from 5.1.  Looking through the
> file it's pretty clear what the [my] original intent was - late breaking
> stuff-ups.

That might be so, but it doesn't mean we couldn't modify the original
intent so that PROBLEMS would serve a slightly different purpose.

Re: [patch/rfc] Add meaningful section titles to PROBLEMS

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 1794 bytes --]


>>> As for some of the others, I think they would be better served as
>>> notes in the documentation (i.e., gdb.texinfo).
> 
> 
> That's a good point - if we want to make users aware of certain
> well-known bugs, then gdb.texinfo is a much more visible place than
> PROBLEMS.  (Nobody will see PROBLEMS other than possibly the specific
> individual, if any, who is installing that version of GDB by hand.)
> GCC has a section of known bugs in its manual; we should follow suit.

Right, now we're getting somewhere.

I've attached the original PROBLEMS file from 5.1.  Looking through the 
file it's pretty clear what the [my] original intent was - late breaking 
stuff-ups.  It strongly suggests using the same criteria as the release 
process:

	"doesn't build, break main; run doesn't work"
however, also including:
	"problems instead fixed in mainline"

would be a good get-out-of goal free card.

A list of "medium"(1) !change-request "bugs" would be easy to generate. 
  Properly @anchor{}ed it could even be cross referenced from the main 
text (but lets walk before we can run).  That could be included in the 
doco as an appendix.

>>>>> Personally, the old division makes more sense to me: a list of all
>>>>> regressions, plus some more serious outstanding issues.  Obviously the
>>>>> header "Regressions since 5.3" should be changed, however.
> 
> 
>>> How about: serious problems that have been fixed in the mainline but
>>> are too nasty to backport?
> 
> 
> The "breakpoints in constructors" bug isn't fixed in mainline,
> either.

(it's actually the GDB doesn't support N:M breakpoints bug but that's 
another story :-) It should be in the doco.

Andrew


(1) "high" gets used by me when doing a release process.  Everyone knows 
that "low" translates to "won't fix" right ;-)

[-- Attachment #2: PROBLEMS --]
[-- Type: text/plain, Size: 1426 bytes --]

		Known problems in GDB 5.1.1

See also the bug database http://www.gnu.org/software/gdb/bugs/


Contrary to the GDB 5.1.1 announcement, the update did not contain
fixes to a i386 floating point problem.  The latest sources do contain
the fix and it will be included in GDB 5.2.


		Known problems in GDB 5.1

hppa2.0-hp-hpux10.20

Due to a problem (conflicting types) with libiberty/regex.c, GDB 5.1
does not build on HP/UX 10.20 when using the HP supplied compiler.

Due to bit rot, GDB 5.1 does not work on HP/UX 10.20 when built with
GCC.


hppa2.0w-hp-hpux11.00

Due to a problem with ltconfig and long argument lines, GDB 5.1 does
not configure on HP/UX 11.00.


alpha-dec-osf5.1

GDB 5.1 has a number of problems on this platform (Ref PR gdb/237).  A
GDB 5.1 built with ``CC="cc -DUSE_LDR_ROUTINES"'' is reported to work
much better.


alpha-dec-osf4.0e

GDB 5.1 is known to have problems on this platform (encounters an
internal error in the symbol table reader).


sparcv9-sun-solaris2.8

There are known problems with building GDB 5.1 using GCC 3.0.x for the
64 bit SPARC target (bad code gen).  You could try a development
version of GCC.


i586-sco-sysv5uw7.1.1

There are known problems with GDB 5.1's thread support on this
platform.  Non-threaded programs should work.


*-*-*

GDB 5.1 assumes that the host C compiler implemends alloca().  GCC is
one such compiler.  This problem should be fixed on the trunk.

Re: [patch/rfc] Add meaningful section titles to PROBLEMS

[David Carlton]

On Fri, 19 Mar 2004 12:33:36 -0500, Andrew Cagney <cagney@gnu.org> said:

>> That aside, I don't like the current design.

> [which "current"? :-)]

Sorry, I meant "your proposed".

> As for some of the others, I think they would be better served as
> notes in the documentation (i.e., gdb.texinfo).

That's a good point - if we want to make users aware of certain
well-known bugs, then gdb.texinfo is a much more visible place than
PROBLEMS.  (Nobody will see PROBLEMS other than possibly the specific
individual, if any, who is installing that version of GDB by hand.)
GCC has a section of known bugs in its manual; we should follow suit.

>> Personally, the old division makes more sense to me: a list of all
>> regressions, plus some more serious outstanding issues.  Obviously the
>> header "Regressions since 5.3" should be changed, however.

> How about: serious problems that have been fixed in the mainline but
> are too nasty to backport?

The "breakpoints in constructors" bug isn't fixed in mainline,
either.

David Carlton
carlton@kealia.com

Re: [patch/rfc] Add meaningful section titles to PROBLEMS

[Andrew Cagney]

> That aside, I don't like the current design.

[which "current"? :-)]

>  The earlier design had a
> list of (sometimes fairly trivial) regressions since 6.0, coupled with
> a much more serious outstanding problem; these two shouldn't be mixed.
> If we decide that we don't want regressions since 6.0 to be in a
> separate section, then we should apply the same criteria to everything
> listed under the header "C++ support" (or whatever), and decide to
> either only list serious bugs or else list every problem that we know
> about.

The current list of C++ problems needs some serious editing.  For instance:

gdb/1512: no canonical way to output names of C++ types
(which is about gdb printing "const char *" vs "char const *")
can hardly be described as "mission critical".  Contrast it to JeffJ's 
discovery that GDB can't debug an NPTL threaded program that does a 
thread delete/create, outch! (but something we likely won't mention in 
problems).

As for some of the others, I think they would be better served as notes 
in the documentation (i.e., gdb.texinfo).

> Personally, the old division makes more sense to me: a list of all
> regressions, plus some more serious outstanding issues.  Obviously the
> header "Regressions since 5.3" should be changed, however.

How about: serious problems that have been fixed in the mainline but are 
too nasty to backport?

Andrew

Re: [patch/rfc] Add meaningful section titles to PROBLEMS

[Andrew Cagney]

> As David C pointed out, "regressions since 5.3" is factually wrong,
> anyways -- the deficiences in that section have always been in gdb.
> 
> I'm in favor of keeping "regressions since 6.0" because those bugs
> really are regressions since 6.0, as demonstrated by testing.
> Most users of gdb 6.1 will be existing users of gdb 6.0 so they
> are going to be interested in what problems to expect when upgrading.

Michael,

As I stated in my cover note, gdb/1560 for instance is a regression 
since GDB _5.0_.  Trying to list regressions is of little value.

We need to make judgement calls here and identify the issues that are 
going to hurt the user (and provide workarounds?).  Giving this file 
meaningful titles (so users don't have to wade through irrelevances such 
as gdb/1512) is a first step.

> I'm willing to abide by whatever Eli, the maintainer, decides.

I don't know who the maintainer is, however doco and releng should be 
"on the same page".

> Michael C
> 
> 2004-03-19  Andrew Cagney  <cagney@redhat.com>
>  
>  	* PROBLEMS: Add general section titles, remove references to
>  	specific releases.

Andrew

Re: [patch/rfc] Add meaningful section titles to PROBLEMS

[David Carlton]

On Fri, 19 Mar 2004 11:16:35 -0500, Andrew Cagney <cagney@gnu.org> said:

> This patch gets rid of the meaningless(1) "Regressions since X.X"
> titles replacing them with functional section titles:

> *** C++ support

> *** Stack backtraces

> *** Misc

> (I think that's all)  The file is re-ordered but none of the contents
> change.

> comments?

As we've discussed earlier, some of what are currently listed as
regressions since 6.0 should be edited to be more clear.

That aside, I don't like the current design.  The earlier design had a
list of (sometimes fairly trivial) regressions since 6.0, coupled with
a much more serious outstanding problem; these two shouldn't be mixed.
If we decide that we don't want regressions since 6.0 to be in a
separate section, then we should apply the same criteria to everything
listed under the header "C++ support" (or whatever), and decide to
either only list serious bugs or else list every problem that we know
about.

Personally, the old division makes more sense to me: a list of all
regressions, plus some more serious outstanding issues.  Obviously the
header "Regressions since 5.3" should be changed, however.

David Carlton
carlton@kealia.com

Re: [patch/rfc] Add meaningful section titles to PROBLEMS

[Michael Elizabeth Chastain]

As David C pointed out, "regressions since 5.3" is factually wrong,
anyways -- the deficiences in that section have always been in gdb.

I'm in favor of keeping "regressions since 6.0" because those bugs
really are regressions since 6.0, as demonstrated by testing.
Most users of gdb 6.1 will be existing users of gdb 6.0 so they
are going to be interested in what problems to expect when upgrading.

I'm willing to abide by whatever Eli, the maintainer, decides.

Michael C

2004-03-19  Andrew Cagney  <cagney@redhat.com>
 
 	* PROBLEMS: Add general section titles, remove references to
 	specific releases.

[patch/rfc] Add meaningful section titles to PROBLEMS

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 605 bytes --]

Hello,

This patch gets rid of the meaningless(1) "Regressions since X.X" titles 
replacing them with functional section titles:

*** C++ support

*** Stack backtraces

*** Misc

(I think that's all)  The file is re-ordered but none of the contents 
change.

comments?

In terms of content, I think any "problem" that is there for more than 
one full release cycle should be documented -- that after all is where 
the user is ment to be looking for information.

Andrew

(1) For instance, the cntrl-c bug is a regression from something like 
5.0 and not 6.0, it's just that it only recently got reported.

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 3943 bytes --]

2004-03-19  Andrew Cagney  <cagney@redhat.com>
 
 	* PROBLEMS: Add general section titles, remove references to
 	specific releases.
 
Index: PROBLEMS
===================================================================
RCS file: /cvs/src/src/gdb/PROBLEMS,v
retrieving revision 1.24
diff -c -r1.24 PROBLEMS
*** PROBLEMS	17 Mar 2004 07:00:41 -0000	1.24
--- PROBLEMS	19 Mar 2004 16:09:11 -0000
***************
*** 3,29 ****
  
  		See also: http://www.gnu.org/software/gdb/bugs/
  
- mips*-*-*
- powerpc*-*-*
- sparc*-*-*
  
! GDB's SPARC, MIPS and PowerPC targets, in 6.0, have not been updated
! to use the new frame mechanism.
  
! People encountering problems with these targets should consult GDB's
! web pages and mailing lists (http://www.gnu.org/software/gdb/) to see
! if there is an update.
! 
! arm-*-*
! 
! GDB's ARM target, in 6.0, has not been updated to use the new frame
! mechanism.
  
! Fortunately the ARM target, in the GDB's mainline sources, has been
! updated so people encountering problems should consider downloading a
! more current GDB (http://www.gnu.org/software/gdb/current).
  
! *** Regressions since gdb 6.0
  
  gdb/826: variables in C++ namespaces have to be enclosed in quotes
  
--- 3,19 ----
  
  		See also: http://www.gnu.org/software/gdb/bugs/
  
  
! *** Misc
  
! gdb/1560: Control-C does not always interrupt GDB.
  
! When GDB is busy processing a command which takes a long time to
! complete, hitting Control-C does not have the expected effect.
! The command execution is not aborted, and the "QUIT" message confirming
! the abortion is displayed only after the command has been completed.
  
! *** C++ support
  
  gdb/826: variables in C++ namespaces have to be enclosed in quotes
  
***************
*** 36,46 ****
  typed in a certain way (e.g. "const char*" as opposed to "const char *"
  or "char const *" or "char const*").
  
- gdb/1505: [regression] gdb prints a bad backtrace for a thread
- 
- When backtracing a thread, gdb doesn't stop until it hits garbage.
- This is sensitive to the operating system and thread library.
- 
  gdb/1512: no canonical way to output names of C++ types
  
  We currently don't have any canonical way to output names of C++ types.
--- 26,31 ----
***************
*** 59,73 ****
  function, not to variables defined with types that are defined somewhere
  outside any function (which most types are).
  
- gdb/1560: Control-C does not always interrupt GDB.
- 
- When GDB is busy processing a command which takes a long time to
- complete, hitting Control-C does not have the expected effect.
- The command execution is not aborted, and the "QUIT" message confirming
- the abortion is displayed only after the command has been completed.
- 
- *** Regressions since gdb 5.3
- 
  gdb/1091: Constructor breakpoints ignored
  gdb/1193: g++ 3.3 creates multiple constructors: gdb 5.3 can't set breakpoints
  
--- 44,49 ----
***************
*** 85,87 ****
--- 61,89 ----
  function with a hidden parameter, but gcc 3.x conforms to a multi-vendor
  ABI for C++ which requires multiple object code functions.
  
+ *** Stack backtraces
+ 
+ gdb/1505: [regression] gdb prints a bad backtrace for a thread
+ 
+ When backtracing a thread, gdb doesn't stop until it hits garbage.
+ This is sensitive to the operating system and thread library.
+ 
+ mips*-*-*
+ powerpc*-*-*
+ sparc*-*-*
+ 
+ GDB's SPARC, MIPS and PowerPC targets, in 6.0, have not been updated
+ to use the new frame mechanism.
+ 
+ People encountering problems with these targets should consult GDB's
+ web pages and mailing lists (http://www.gnu.org/software/gdb/) to see
+ if there is an update.
+ 
+ arm-*-*
+ 
+ GDB's ARM target, in 6.0, has not been updated to use the new frame
+ mechanism.
+ 
+ Fortunately the ARM target, in the GDB's mainline sources, has been
+ updated so people encountering problems should consider downloading a
+ more current GDB (http://www.gnu.org/software/gdb/current).