- Known problems in GDB 6.2
+ Known problems in GDB 6.5
See also: http://www.gnu.org/software/gdb/bugs/
*** Build problems
-build/1458: compile failed on hpux11
+build/1411: build fails on hpux 10.20 and hpux 11.00 with CMA threads
-GDB has build problems on HP/UX 11 with some versions of the HP
-Ansi C compiler. (GCC works fine).
+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:
-The problem happens when compiling intl/bindtextdom.c.
-The error is:
+ ../../gdb/hpux-thread.c:222: variable-size type declared outside of any function
- cc: "gettextP.h", line 50: error 1000: Unexpected symbol: "SWAP".
- cc: panic 2017: Cannot recover from earlier errors, terminating.
- *** Error exit code 1
+This happens only if the CMA thread package is installed.
-This is a problem with the 'inline' keyword in gettextP.h.
-The workaround is to disable 'inline' before building gdb:
+As a workaround, you can disable support for CMA threads
+by editing the file gdb/configure. Find the line:
- export ac_cv_c_inline=no
+ if test -f /usr/include/dce/cma_config.h ; then
-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.
+And replace it with:
-This problem might also happen with other C compilers.
+ if false ; then
*** Misc
function with a hidden parameter, but gcc 3.x conforms to a multi-vendor
ABI for C++ which requires multiple object code functions.
-*** Signal handlers
-
-On many systems an attempt to single-step a system-call instruction
-results in two or more instructions being executed (the system-call,
-and one or more instructions following).
-
-When attempting to single-step through a signal trampoline, this
-problem may result the program unintentionally running to completion,
-or re-execute the faulting instruction, or even corrupting the program
-counter.
-
-Ref: PR breakpoints/1702.
-
-*** 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.
-
*** Threads
threads/1650: manythreads.exp
-A program which creates many threads which exit very quickly (hundreds
-of thousands of threads in the test program) can cause gdb to generate
-an internal error. The internal error often looks like:
+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.
- lin-lwp.c:744: internal-error: stop_callback: Assertion `lp->status == 0' failed.
- A problem internal to GDB has been detected.
- further debugging may prove unreliable.
- Quit this debugging session? (y or n)
+threads/2137: Native Solaris Thread Debugging broken.
-This has been observed on native i686-pc-linux-gnu with linuxthreads,
-the old threading model. With NPTL threads, this internal error has not
-been observed.
+Use GDB 6.4 if thread debugging is needed on Solaris.
projects / deliverable / binutils-gdb.git / blobdiff