Below is a list of problems identified during the GDB 5.0 release
cycle. People hope to have these problems fixed in 5.1.
---
-
-Hardware watchpint problems on x86 OSes, including Linux:
-
-1. Delete/disable hardware watchpoints should free hardware debug
-registers.
-2. Watch for different values on a viariable with one hardware debug
-register.
-
-According to Eli Zaretskii <eliz@delorie.com>:
-
-These are not GDB/ia32 issues per se: the above features are all
-implemented in the DJGPP port of GDB and work in v5.0. Every
-x86-based target should be able to lift the relevant parts of
-go32-nat.c and use them almost verbatim. You get debug register
-sharing through reference counts, and the ability to watch large
-regions (up to 16 bytes) using multiple registers. (The required
-infrastructure in high-level GDB application code, mostly in
-breakpoint.c, is also working since v5.0.)
-
---
-
-RFD: infrun.c: No bpstat_stop_status call after proceed over break?
-http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00665.html
-
-GDB misses watchpoint triggers after proceeding over a breakpoint on
-x86 targets.
-
---
-
-x86 linux GDB and SIGALRM (???)
-http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00803.html
+-- 2001-03-08
-This problem has been fixed, but a regression test still needs to be
-added to the testsuite:
-http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00309.html
-
-Mark
+Update GDB's coding standard documentation. Known topics:
---
+ o alloca/malloc et.al.
-Can't build IRIX -> arm GDB.
-http://sourceware.cygnus.com/ml/gdb-patches/2000-04/msg00356.html
+ o typedef and structs
-David Whedon writes:
-> Now I'm building for an embedded arm target. If there is a way of turning
-> remote-rdi off, I couldn't find it. It looks like it gets built by default
-> in gdb/configure.tgt(line 58) Anyway, the build dies in
-> gdb/rdi-share/unixcomm.c. SERPORT1 et. al. never get defined because we
-> aren't one of the architectures supported.
+ o ISO-C
---
+and most likely also:
-Problem with weak functions
-http://sourceware.cygnus.com/ml/gdb/2000-05/msg00060.html
-
-Dan Nicolaescu writes:
-> It seems that gdb-4.95.1 does not display correctly the function when
-> stoping in weak functions.
->
-> It stops in a function that is defined as weak, not in the function
-> that is actualy run...
-
---
-
-GDB 5.0 doesn't work on Linux/SPARC
-
---
-
-Thread support. Right now, as soon as a thread finishes and exits,
-you're hosed. This problem is reported once a week or so.
+ o include conventions
--
--
-Re: GDB 5.0.1?
-http://sources.redhat.com/ml/gdb/2000-07/msg00038.html
+x86 linux GDB and SIGALRM (???)
+http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00803.html
+
+This problem has been fixed, but a regression test still needs to be
+added to the testsuite:
+http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00309.html
-Is the Solaris 8 x86 problem fixed? When you configure it, configure
-incorrectly determines that I have no curses.h. This causes mucho
-compilation errors later on.
+Mark
-Simply editing the config.h to define CURSES_H fixes the problem, and
-then the build works fine.
+[The test has been submitted for approval - cagney]
-The status for this problem:
+--
-Solaris 8 x86 (PIII-560)
-gcc 2.95.2
+RFD: infrun.c: No bpstat_stop_status call after proceed over break?
+http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00665.html
-I had the same problem with several of the snapshots shortly before
-5.0 became official, and 5.0 has the same problem.
+GDB misses watchpoint triggers after proceeding over a breakpoint on
+x86 targets.
-I sent some mail in about it long ago, and never saw a reply.
+--
-I haven't had time to figure it out myself, especially since I get all
-confused trying to figure out what configure does, I was happy to find
-the workaround.
+GDB 5.0 doesn't work on Linux/SPARC
-Mike
+There are two parts to this.
+
+ o GDB 5.0 doesn't work on GNU/Linux/SPARC32
+
+ o GDB 5.0 doesn't work on the new target
+ GNU/Linux/SPARC64
+
+GDB does build on both these targets.
+
+The first problem is the one that should be fixed.
--
Enable MI by default. Old code can be deleted after 5.1 is out.
+Issues:
+
+ o syntax change where a list would
+ look like:
+ [ foo=a, foo=b, foo=c ]
+ instead of
+ { foo=a, foo=b, foo=c }
+
+ o kill off the idea of a reverse
+ query.
+
+ o review test cases
+
+ o enable it
+
--
Pascal (Pierre Muller, David Taylor)
Indent -gnu ?
http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00496.html
+[I think this has been merged, need to confirm - cagney]
+
--
Java (Anthony Green, David Taylor)
Patch: handle N_MAIN stab
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00527.html
---
+-- 2001-03-08
-[Comming...]
+Add CRIS target.
-Modify gdb to work correctly with Pascal.
+A predicate to this is the multi-arching of SOFTWARE_SINGLE_STEP(). A
+patch has been submitted.
--
-Revised UDP support (was: Re: [Fwd: [patch] UDP transport support])
-http://sourceware.cygnus.com/ml/gdb-patches/2000-04/msg00000.html
+ GDB 5.1 - Cleanups
+ ==================
-(Broken) support for GDB's remote protocol across UDP is to be
-included in the follow-on release.
+The following code cleanups will hopefully be applied to GDB 5.1.
-It should be noted that UDP can only work when the [Gg] packet fits in
-a single UDP packet.
+-- 2001-03-08
-There is also much debate over the merit of this.
+Resolve the status of all broken targets as identified by the MAINTAINERS
+file.
--
- GDB 5.1 - Cleanups
- ==================
-
-The following code cleanups will hopefully be applied to GDB 5.1.
+Change documentation to GFDL license.
---
+``It is time to make an effort to start using the GFDL more
+thoroughly. Would all GNU maintainers please change the license to
+the GFDL, for all manuals and other major documentation files?
-Delete macro TARGET_BYTE_ORDER_SELECTABLE.
+The GFDL and some instructions for using it can be found in
+http://www.gnu.org/copyleft/''
-Patches in the database.
+ RMS
--
--
-Purge PARAMS.
-
-Eliminate all uses of PARAMS in GDB's source code.
+ GDB 5.1 - Known Problems
+ ========================
--
-printcmd.c (print_address_numeric):
+z8k
-NOTE: This assumes that the significant address information is kept in
-the least significant bits of ADDR - the upper bits were either zero
-or sign extended. Should ADDRESS_TO_POINTER() or some
-ADDRESS_TO_PRINTABLE() be used to do the conversion?
+The z8k has suffered bit rot and is known to not build. The problem
+was occuring in the opcodes directory.
--
-Compiler warnings.
+Solaris 8 x86 CURSES_H problem
+http://sources.redhat.com/ml/gdb/2000-07/msg00038.html
-Eliminate all warnings for at least one host/target for the flags:
--Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses
--Wpointer-arith -Wuninitialized
+The original problem was worked around with:
---
+ 2000-06-06 Michael Snyder <msnyder@cygnus.com>
-Follow through `make check' with --enable-shared.
+ * configure.in: Enable autoconf to find curses.h on Solaris 2.8.
+ * configure: Regenerate.
-When the srcware tree is configured with --enable-shared, the `expect'
-program won't run properly. Jim Wilson found out gdb has a local hack
-to set LD_LIBRARY_PATH, but, AFAIK, no other project has been hacked
-similarly.
-
-http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00845.html
+When building both GDB and SID using the same source tree the problem
+will still occure. sid/component/configure.in mis-configures
+<curses.h> and leaves wrong information in the config cache.
--
--
-Fix at least one thread bug.
+Thread support. Right now, as soon as a thread finishes and exits,
+you're hosed. This problem is reported once a week or so.
--
--
-Objective C/C++ Support. Bu hopefully sooner...
+GCC 3.0 ABI support (but hopefully sooner...).
+
+--
+
+Objective C/C++ support (but hopefully sooner...).
--
--
-Eliminate more compiler warnings.
+Remove old code that does not use ui_out functions and all the related
+"ifdef"s. This also allows the elimination of -DUI_OUT from
+Makefile.in and configure.in.
+
+--
+
+Compiler warnings.
+
+Eliminate all warnings for at least one host/target for the flags:
+-Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses
+-Wpointer-arith -Wuninitialized
--
The current convention is (kind of) to use $(<header>_h) in all
dependency lists. It isn't done in a consistent way.
+--
+
+ GDB 5.2 - Known Problems
+ ========================
+
--
Code Cleanups: General
--
+Revised UDP support (was: Re: [Fwd: [patch] UDP transport support])
+http://sourceware.cygnus.com/ml/gdb-patches/2000-04/msg00000.html
+
+(Broken) support for GDB's remote protocol across UDP is to be
+included in the follow-on release.
+
+It should be noted that UDP can only work when the [Gg] packet fits in
+a single UDP packet.
+
+There is also much debate over the merit of this.
+
+--
+
+Can't build IRIX -> arm GDB.
+http://sourceware.cygnus.com/ml/gdb-patches/2000-04/msg00356.html
+
+David Whedon writes:
+> Now I'm building for an embedded arm target. If there is a way of turning
+> remote-rdi off, I couldn't find it. It looks like it gets built by default
+> in gdb/configure.tgt(line 58) Anyway, the build dies in
+> gdb/rdi-share/unixcomm.c. SERPORT1 et. al. never get defined because we
+> aren't one of the architectures supported.
+
+--
+
+Problem with weak functions
+http://sourceware.cygnus.com/ml/gdb/2000-05/msg00060.html
+
+Dan Nicolaescu writes:
+> It seems that gdb-4.95.1 does not display correctly the function when
+> stoping in weak functions.
+>
+> It stops in a function that is defined as weak, not in the function
+> that is actually run...
+
+--
+
+Follow through `make check' with --enable-shared.
+
+When the srcware tree is configured with --enable-shared, the `expect'
+program won't run properly. Jim Wilson found out gdb has a local hack
+to set LD_LIBRARY_PATH, but, AFAIK, no other project has been hacked
+similarly.
+
+http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00845.html
+
+--
+
+Delete macro TARGET_BYTE_ORDER_SELECTABLE.
+
+Patches in the database.
+
+--
+
+printcmd.c (print_address_numeric):
+
+NOTE: This assumes that the significant address information is kept in
+the least significant bits of ADDR - the upper bits were either zero
+or sign extended. Should ADDRESS_TO_POINTER() or some
+ADDRESS_TO_PRINTABLE() be used to do the conversion?
+
+--
+
The BFD directory requires bug-fixed AUTOMAKE et.al.
AUTOMAKE 1.4 incorrectly set the TEXINPUTS environment variable. It
--
-Rely on BFD_BIG_ENDIAN and BFD_LITTLE_ENDIAN instead of host dependant
+Rely on BFD_BIG_ENDIAN and BFD_LITTLE_ENDIAN instead of host dependent
BIG_ENDIAN and LITTLE_ENDIAN.
--
--
-Replace asprintf() calls with xasprintf() calls.
-
-As with things like strdup() most calls to asprintf() don't check the
-return value.
-
---
-
-Replace strsave() + mstrsave() with libiberty:xstrdup().
-
---
-
Replace savestring() with something from libiberty.
An xstrldup()? but that would have different semantics.
--
-Eliminate mmalloc() from GDB.
+Eliminate mmalloc(), mstrsave() et.al. from GDB.
Also eliminate it from defs.h.
--
-Add __LINE__ and __FILE__ to internal_error().
-
---
-
GDB probably doesn't build on FreeBSD pre 2.2.x
http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00378.html
Apart from the d30v, are there any sim/common simulators that make use
of this?
-A brief summary of what happended is that sim/common/sim-break.c was
+A brief summary of what happened is that sim/common/sim-break.c was
created as a good idea. It turned out a better idea was to use
SIM_SIGBREAK and have GDB pass back sim_resume (..., SIGBREAK).
Move remote_remove_hw_breakpoint, remote_insert_hw_breakpoint,
remote_remove_watchpoint, remote_insert_watchpoint into target vector.
+--
+
+Eliminate ``extern'' from C files.
+
+--
+
+Replace ``STREQ()'' et.al. with ``strcmp() == 0'' et.al.
+
+Extreme care is recommeded - perhaps only modify tests that are
+exercised by the testsuite (as determined using some type of code
+coverage analysis).
+
+--
+
+Replace the file gdb/CONTRIBUTE with a file that is generated from the
+gdb/doc/*.texinfo directory.
+
--
New Features and Fixes
--
+Hardware watchpoint problems on x86 OSes, including Linux:
+
+1. Delete/disable hardware watchpoints should free hardware debug
+registers.
+2. Watch for different values on a viariable with one hardware debug
+register.
+
+According to Eli Zaretskii <eliz@delorie.com>:
+
+These are not GDB/ia32 issues per se: the above features are all
+implemented in the DJGPP port of GDB and work in v5.0. Every
+x86-based target should be able to lift the relevant parts of
+go32-nat.c and use them almost verbatim. You get debug register
+sharing through reference counts, and the ability to watch large
+regions (up to 16 bytes) using multiple registers. (The required
+infrastructure in high-level GDB application code, mostly in
+breakpoint.c, is also working since v5.0.)
+
+--
+
Add built-by, build-date, tm, xm, nm and anything else into gdb binary
so that you can see how the GDB was created.
``(gdb) catch signal SIGNAL''
-Overlaps with ``handle SIGNAL'' but the implied behavour is different.
+Overlaps with ``handle SIGNAL'' but the implied behavior is different.
You can attach commands to a catch but not a handle. A handle has a
limited number of hardwired actions.
Replace the code that uses the host FPU with an emulator of the target
FPU.
+--
+
+The "ocd reset" command needs to flush the dcache, which requires breaking
+the abstraction layer between the target independent and target code. One
+way to address this is provide a generic "reset" command and target vector.
+
+http://sources.redhat.com/ml/gdb-patches/2000-10/msg00011.html
+
--
Thread Support
If / when GDB starts to support the debugging of multi-processor
(rather than multi-thread) applications the symtab code will need to
-be updated a little so that several independant symbol tables are
+be updated a little so that several independent symbol tables are
active at a given time.
The other interesting change is a clarification of the exact meaning
construct a virtual frame-handle from the stack pointer and various
other bits of string.
-Unfortunatly GDB still treats this synthetic FP register as though it
+Unfortunately GDB still treats this synthetic FP register as though it
is real. That in turn really confuses users (arm and ``print $fp'' VS
``info registers fp''). The synthetic FP should be separated out of
the true register set presented to the user.
|
map random cache
bytes to target
- dependant i-face
+ dependent i-face
/|\
|
- target dependant
+ target dependent
such as [gG] packet
or ptrace buffer
o a mechanism that clearly separates the
gdb internal register cache from any
- target (not architecture) dependant
+ target (not architecture) dependent
specifics such as [gG] packets.
Of course, like anything, it sounds good in theory. In reality, it
The name is wrong for starters. ``target_signal'' should probably be
``gdb_signal''. ``from_host'' should be ``from_target_signal''.
-After that it needs to be multi-arched and made independant of any
+After that it needs to be multi-arched and made independent of any
host signal numbering.
--
--
-Make MI interface accessable from existing CLI.
+Make MI interface accessible from existing CLI.
--
open an asynchronous target that may need to perform background tasks
as part of the ``attach'' phase.
-Unfortunatly, due to limitations in the old/creaking command.h
+Unfortunately, due to limitations in the old/creaking command.h
interface, that isn't possible. The function being called isn't told
of the ``xxx'' or any other context information.