darling-gdb/gdb/PROBLEMS
Andrew Cagney bc124bd316 2002-12-10 Andrew Cagney <ac131313@redhat.com>
* PROBLEMS: Delete reference to PR gdb/725.
2002-12-10 21:24:47 +00:00

68 lines
2.0 KiB
Plaintext

Known problems in GDB 5.3
See also: http://www.gnu.org/software/gdb/bugs/
*-*-freebsd*
---------------
Due to a kernel bug (kern/35175), detaching from an attached process
will very likely cause the process to be stop or die with a Trace/BPT
trap.
i386-*-freebsd[34]*
-------------------
There is a bug (bin/41671) in FreeBSD's gcc that causes it to emit bad
debug information when using the stabs format (which is the default).
As a result GDB tends to place breakpoints on functions before the
function prologue, and information about function parameters and local
variables is lost. In earlier versions of GDB the effects were rather
limited, but starting with GDB 5.3 the influence is much more
prominent. As a workaround, compile your code with -gdwarf-2.
hppa2.0-hp-hpux10.20
--------------------
gdb/487: The top level make files used to build GDB are not compatible
with HP/UX make. As a workaround, use GNU make.
gdb/486: The HP/UX C compiler defaults to K&R mode but GDB only builds
with an ISO C compiler. The top level configuration incorrectly sets
CC to `cc' instead of `cc -Ae'. As a workaround, the correct compiler
can be specified as part of the configuration vis:
$ 'CC=cc -Ae' ./configure
s390*-*-*
---------
gdb/513: GDB does not build on s390 GNU/Linux. The problem should be
fixed in more recent sources.
i386-*-freebsd4.4*
------------------
gdb/455: GDB doesn't build on a FreeBSD 4.4-STABLE system. The
problem is still being investigated.
alpha*-*-osf*
-------------
gdb/816: When building GDB with GCC 3.0.1, GDB is unable to load a core
file properly. It generates several errors and warnings regarding
unhandled core file section types, incorrect endianness, the failure to
load the registers. Are also incorrectly reported: The program name, the
cause of the program death, and the call stack at the moment of the
death. This problem has been reported on alpha-osf4.0f and alpha-osf5.1a.
To work-around the problem, add -D__digital__ to the CFLAGS when
building GDB vis:
$ make CFLAGS='-O2 -D__digital__'