gdb/PROBLEMS

   1
   2                         Known problems in GDB 6.2
   3
   4                 See also: http://www.gnu.org/software/gdb/bugs/
   5
   6
   7 *** Build problems
   8
   9 build/1411: build fails on hpux 10.20 and hpux 11.00 with CMA threads
  10
  11 GDB does not build on HP/UX 10.20 or HP/UX 11.00 if the CMA
  12 thread package is installed.  The compile error is:
  13
  14   ../../gdb/hpux-thread.c:222: variable-size type declared outside of any function
  15
  16 This happens only if the CMA thread package is installed.
  17
  18 As a workaround, you can disable support for CMA threads
  19 by editing the file gdb/configure.  Find the line:
  20
  21   if test -f /usr/include/dce/cma_config.h ; then
  22
  23 And replace it with:
  24
  25   if false ; then
  26
  27 build/1458: compile failed on hpux11
  28
  29 GDB has build problems on HP/UX 11 with some versions of the HP
  30 Ansi C compiler.  (GCC works fine).
  31
  32 The problem happens when compiling intl/bindtextdom.c.
  33 The error is:
  34
  35   cc: "gettextP.h", line 50: error 1000: Unexpected symbol: "SWAP".
  36   cc: panic 2017: Cannot recover from earlier errors, terminating.
  37   *** Error exit code 1
  38
  39 This is a problem with the 'inline' keyword in gettextP.h.
  40 The workaround is to disable 'inline' before building gdb:
  41
  42   export ac_cv_c_inline=no
  43
  44 This problem happens only with some versions of the HP Ansi C compiler.
  45 Versions A.11.01.25171.GP and B.11.11.28706.GP have both been observed
  46 to work; version B.11.11.04 gets the build error and needs the
  47 workaround.
  48
  49 This problem might also happen with other C compilers.
  50
  51 *** Misc
  52
  53 gdb/1560: Control-C does not always interrupt GDB.
  54
  55 When GDB is busy processing a command which takes a long time to
  56 complete, hitting Control-C does not have the expected effect.
  57 The command execution is not aborted, and the "QUIT" message confirming
  58 the abortion is displayed only after the command has been completed.
  59
  60 *** C++ support
  61
  62 gdb/931: GDB could be more generous when reading types C++ templates on input
  63
  64 When the user types a template, GDB frequently requires the type to be
  65 typed in a certain way (e.g. "const char*" as opposed to "const char *"
  66 or "char const *" or "char const*").
  67
  68 gdb/1512: no canonical way to output names of C++ types
  69
  70 We currently don't have any canonical way to output names of C++ types.
  71 E.g. "const char *" versus "char const *"; more subtleties arise when
  72 dealing with templates.
  73
  74 gdb/1516: [regression] local classes, gcc 2.95.3, dwarf-2
  75
  76 With gcc 2.95.3 and the dwarf-2 debugging format, classes which are
  77 defined locally to a function include the demangled name of the function
  78 as part of their name.  For example, if a function "foobar" contains a
  79 local class definition "Local", gdb will say that the name of the class
  80 type is "foobar__Fi.0:Local".
  81
  82 This applies only to classes where the class type is defined inside a
  83 function, not to variables defined with types that are defined somewhere
  84 outside any function (which most types are).
  85
  86 gdb/1588: names of c++ nested types in casts must be enclosed in quotes
  87
  88 You must type
  89   (gdb) print ('Foo::Bar') x
  90 or
  91   (gdb) print ('Foo::Bar' *) y
  92 instead of
  93   (gdb) print (Foo::Bar) x
  94 or
  95   (gdb) print (Foo::Bar *) y
  96 respectively.
  97
  98 gdb/1091: Constructor breakpoints ignored
  99 gdb/1193: g++ 3.3 creates multiple constructors: gdb 5.3 can't set breakpoints
 100
 101 When gcc 3.x compiles a C++ constructor or C++ destructor, it generates
 102 2 or 3 different versions of the object code.  These versions have
 103 unique mangled names (they have to, in order for linking to work), but
 104 they have identical source code names, which leads to a great deal of
 105 confusion.  Specifically, if you set a breakpoint in a constructor or a
 106 destructor, gdb will put a breakpoint in one of the versions, but your
 107 program may execute the other version.  This makes it impossible to set
 108 breakpoints reliably in constructors or destructors.
 109
 110 gcc 3.x generates these multiple object code functions in order to
 111 implement virtual base classes.  gcc 2.x generated just one object code
 112 function with a hidden parameter, but gcc 3.x conforms to a multi-vendor
 113 ABI for C++ which requires multiple object code functions.
 114
 115 *** Signal handlers
 116
 117 On many systems an attempt to single-step a system-call instruction
 118 results in two or more instructions being executed (the system-call,
 119 and one or more instructions following).
 120
 121 When attempting to single-step through a signal trampoline, this
 122 problem may result the program unintentionally running to completion,
 123 or re-execute the faulting instruction, or even corrupting the program
 124 counter.
 125
 126 Ref: PR breakpoints/1702.
 127
 128 *** Stack backtraces
 129
 130 GDB's core code base has been updated to use a new backtrace
 131 mechanism.  This mechanism makes it possible to support new features
 132 such DWARF 2 Call Frame Information (which in turn makes possible
 133 backtraces through optimized code).
 134
 135 Since this code is new, it is known to still have a few problems:
 136
 137 gdb/1505: [regression] gdb prints a bad backtrace for a thread
 138
 139 When backtracing a thread, gdb does not stop when it reaches the
 140 outermost frame, instead continuing until it hits garbage.  This is
 141 sensitive to the operating system and thread library.
 142
 143 *** Threads
 144
 145 threads/1650: manythreads.exp
 146
 147 On GNU/Linux systems that use the old LinuxThreads thread library, a
 148 program rapidly creating and deleting threads can confuse GDB leading
 149 to an internal error.
 150
 151 This problem does not occur on newer systems that use the NPTL
 152 library, and did not occur with GDB 6.1.