gdb/PROBLEMS ?

[Pedro Alves <pedro at codesourcery dot com>]

I looked over the described problems in gdb/PROBLEMS, and, it looks
to me that all of them fall in one of two categories: either
they've been fixed already, or aren't worth mentioning here.
Anyone wants to double check, or believes otherwise?  I'll
be happy to adjust the patch.

After the patch, all that's left is:
=======================================================================

			Known problems in GDB 7.1.50

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

None worth mentioning here.
=======================================================================

While here: we haven't been maintaining gdb/PROBLEMS since 6.5,
it seems.

gdbint.texinfo has this to say:

 @section Before the Branch

 The most important objective at this stage is to find and fix simple
 changes that become a pain to track once the branch is created.  For
 instance, configuration problems that stop @value{GDBN} from even
 building.  If you can't get the problem fixed, document it in the
 @file{gdb/PROBLEMS} file.

and 

 Don't fix something on the branch unless/until it is also fixed in the
 trunk.  If this isn't possible, mentioning it in the @file{gdb/PROBLEMS}
 file is better than committing a hack.
 @item

I think that if we're not sticking with the policy
of maintaining the file anymore, we should get rid of the file
entirely.  If not, we should update the version reference in this file
as well.  But meanwhile, this is just as good (or better! GDB has
no problems!), and better than pointing at problems that are gone
already, for sure.

-- 
Pedro Alves

2010-05-02  Pedro Alves  <pedro@codesourcery.com>

	* PROBLEMS: Remove mention of all problems.

---
 gdb/PROBLEMS |  102 +----------------------------------------------------------
 1 file changed, 2 insertions(+), 100 deletions(-)

Index: src/gdb/PROBLEMS
===================================================================
--- src.orig/gdb/PROBLEMS	2010-04-19 02:05:42.000000000 +0100
+++ src/gdb/PROBLEMS	2010-05-02 17:12:46.000000000 +0100
@@ -1,104 +1,6 @@
 
-			Known problems in GDB 6.5
+			Known problems in GDB 7.1.50
 
 		See also: http://www.gnu.org/software/gdb/bugs/
 
-
-*** Build problems
-
-build/1411: build fails on hpux 10.20 and hpux 11.00 with CMA threads
-
-GDB does not build on HP/UX 10.20 or HP/UX 11.00 if the CMA
-thread package is installed.  The compile error is:
-
-  ../../gdb/hpux-thread.c:222: variable-size type declared outside of any function
-
-This happens only if the CMA thread package is installed.
-
-As a workaround, you can disable support for CMA threads
-by editing the file gdb/configure.  Find the line:
-
-  if test -f /usr/include/dce/cma_config.h ; then
-
-And replace it with:
-
-  if false ; then
-
-*** 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/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
-typed in a certain way (e.g. "const char*" as opposed to "const char *"
-or "char const *" or "char const*").
-
-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.
-E.g. "const char *" versus "char const *"; more subtleties arise when
-dealing with templates.
-
-gdb/1516: [regression] local classes, gcc 2.95.3, dwarf-2
-
-With gcc 2.95.3 and the dwarf-2 debugging format, classes which are
-defined locally to a function include the demangled name of the function
-as part of their name.  For example, if a function "foobar" contains a
-local class definition "Local", gdb will say that the name of the class
-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
-
-When gcc 3.x compiles a C++ constructor or C++ destructor, it generates
-2 or 3 different versions of the object code.  These versions have
-unique mangled names (they have to, in order for linking to work), but
-they have identical source code names, which leads to a great deal of
-confusion.  Specifically, if you set a breakpoint in a constructor or a
-destructor, gdb will put a breakpoint in one of the versions, but your
-program may execute the other version.  This makes it impossible to set
-breakpoints reliably in constructors or destructors.
-
-gcc 3.x generates these multiple object code functions in order to
-implement virtual base classes.  gcc 2.x generated just one object code
-function with a hidden parameter, but gcc 3.x conforms to a multi-vendor
-ABI for C++ which requires multiple object code functions.
-
-*** Threads
-
-threads/1650: manythreads.exp
-
-On GNU/Linux systems that use the old LinuxThreads thread library, a
-program rapidly creating and deleting threads can confuse GDB leading
-to an internal error.
-
-This problem does not occur on newer systems that use the NPTL
-library, and did not occur with GDB 6.1.
-
-threads/2137: Native Solaris Thread Debugging broken.
-
-Use GDB 6.4 if thread debugging is needed on Solaris.
+None worth mentioning here.