This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



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 ;-)
		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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]