From: Pedro Alves Date: Thu, 29 Jul 2010 14:48:58 +0000 (+0000) Subject: * PROBLEMS: Remove mention of all problems. X-Git-Tag: sid-snapshot-20100801~25 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=0b29bddec8f241f1db08b1ccc48df65fc260dc31;p=external%2Fbinutils.git * PROBLEMS: Remove mention of all problems. --- diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 66e74f73..e52d24a 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,7 @@ +2010-07-29 Pedro Alves + + * PROBLEMS: Remove mention of all problems. + 2010-07-28 Pedro Alves PR build/11848 diff --git a/gdb/PROBLEMS b/gdb/PROBLEMS index 030f8ed..974f4f0 100644 --- a/gdb/PROBLEMS +++ b/gdb/PROBLEMS @@ -1,104 +1,6 @@ - Known problems in GDB 6.5 + Known problems in GDB 7.2.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.