X-Git-Url: http://git.efficios.com/?a=blobdiff_plain;f=gdb%2FPROBLEMS;h=4e1327f57cb8b75d40feccc2fd6aa85a7bad5e00;hb=refs%2Fheads%2Fconcurrent-displaced-stepping-2020-04-01;hp=7baf1d2e831d8be253c643f3b919d6a377821836;hpb=860660cb5bba4aeb570c609c5d3a3288468f2adf;p=deliverable%2Fbinutils-gdb.git diff --git a/gdb/PROBLEMS b/gdb/PROBLEMS index 7baf1d2e83..4e1327f57c 100644 --- a/gdb/PROBLEMS +++ b/gdb/PROBLEMS @@ -1,131 +1,5 @@ +Known problems in GDB can be found by searching GDB's Bugzilla, here: - Known problems in GDB 6.2 + https://sourceware.org/bugzilla/query.cgi?product=gdb - See also: http://www.gnu.org/software/gdb/bugs/ - - -*** Build problems - -build/1458: compile failed on hpux11 - -GDB has build problems on HP/UX 11 with some versions of the HP -Ansi C compiler. (GCC works fine). - -The problem happens when compiling intl/bindtextdom.c. -The error is: - - cc: "gettextP.h", line 50: error 1000: Unexpected symbol: "SWAP". - cc: panic 2017: Cannot recover from earlier errors, terminating. - *** Error exit code 1 - -This is a problem with the 'inline' keyword in gettextP.h. -The workaround is to disable 'inline' before building gdb: - - export ac_cv_c_inline=no - -This problem happens only with some versions of the HP Ansi C compiler. -Versions A.11.01.25171.GP and B.11.11.28706.GP have both been observed -to work; version B.11.11.04 gets the build error and needs the -workaround. - -This problem might also happen with other C compilers. - -*** 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. - -*** Stack backtraces - -GDB's core code base has been updated to use a new backtrace -mechanism. This mechanism makes it possible to support new features -such DWARF 2 Call Frame Information (which in turn makes possible -backtraces through optimized code). - -Since this code is new, it is known to still have a few problems: - -gdb/1505: [regression] gdb prints a bad backtrace for a thread - -When backtracing a thread, gdb does not stop when it reaches the -outermost frame, instead continuing until it hits garbage. This is -sensitive to the operating system and thread library. - -hppa*-*-* -mips*-*-* - -The MIPS and HPPA backtrace code has only very recently been updated -to use GDB's new frame mechanism. At present there are still a few -problems, in particular backtraces through signal handlers do not -work. - -People encountering problems with these architectures should consult -GDB's web pages and mailing lists (http://www.gnu.org/software/gdb/) -to see if there are updates. - -powerpc*-*-* - -PowerPC architecture support, in 6.1, does not use the new frame code. - -Fortunately, PowerPC architecture support, in GDB's mainline sources, -have been updated. People encountering problems should consider -downloading a more current snapshot of GDB -(http://www.gnu.org/software/gdb/current/). +For help on searching, click the "Help" link at the top of the page.