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

[Andrew Cagney <cagney@gnu.org>]

[-- 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.