Fix -Werror -Wuninitialized warnings.
[deliverable/binutils-gdb.git] / gdb / TODO
index 8d0785da85a00d9697aa4ea4c45a491d54242e53..55f6084cb8d9c2c453c9cf982721232ed07ac5a0 100644 (file)
--- a/gdb/TODO
+++ b/gdb/TODO
@@ -10,77 +10,19 @@ find out whether anyone else is working on it.
 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:
+-- 2001-03-08
 
-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
+Update GDB's coding standard documentation.  Known topics:
 
-GDB misses watchpoint triggers after proceeding over a breakpoint on
-x86 targets.
+       o     alloca/malloc et.al.
 
---
+       o     typedef and structs
 
-x86 linux GDB and SIGALRM (???)
-http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00803.html
+       o       ISO-C
 
-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
+and most likely also:
 
-Mark
-
---
-
-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... 
-
---
-
-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
 
 --
 
@@ -104,31 +46,39 @@ Mark
 
 --
 
-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
+
+Mark
 
-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.
+[The test has been submitted for approval - cagney]
 
-Simply editing the config.h to define CURSES_H fixes the problem, and
-then the build works fine.
+--
+
+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.
 
-The status for this problem:
+--
+
+GDB 5.0 doesn't work on Linux/SPARC
 
-Solaris 8 x86 (PIII-560)
-gcc 2.95.2
+There are two parts to this.
 
-I had the same problem with several of the snapshots shortly before
-5.0 became official, and 5.0 has the same problem.
+      o          GDB 5.0 doesn't work on GNU/Linux/SPARC32
 
-I sent some mail in about it long ago, and never saw a reply.
+      o          GDB 5.0 doesn't work on the new target
+         GNU/Linux/SPARC64
 
-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 does build on both these targets.
 
-Mike
+The first problem is the one that should be fixed.
 
 --
 
@@ -141,6 +91,21 @@ The following new features should be included in 5.1.
 
 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)
@@ -154,6 +119,8 @@ http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00521.html
 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)
@@ -171,37 +138,90 @@ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00515.html
 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-22
 
-There is also much debate over the merit of this.
+Resolve the build status of all broken targets as identified by the
+MAINTAINERS file.
 
---
+       o       arm-* vs NetBSD's lack of ``unix''
+       o       arm-* vs IRIX (see below)
 
-               GDB 5.1 - Cleanups
-               ==================
+       o       delete m88k?
 
-The following code cleanups will hopefully be applied to GDB 5.1.
+       o       delete mpw?
+
+-- 2001-03-15
+
+                       Obsolete some targets.
+
+Possible selection criteria are:
+
+       o       uses a deprecated feature
+
+       o       doesn't build
+
+       o       doesn't have a maintainer
+
+Steps:            
+         
+       o       post proposals to gdb@ (DONE)
+
+       o       post announcement to gdb-announce@
+               crossed with gdb@ reply-to to gdb@
+               (DONE)
+
+                       ns32k-*-mach3*
+                       ns32k-umax-*
+                       ns32k-utek-sysv*
+                       tic80-*
+                       m68*-isi-*
+                       m68*-sony-*
+                       m68*-rom68k-*
+                       m68*-*bug-*
+                       m68*-monitor-*
+                       m68*-est-*
+                       a29k-ultra3
+                       powerpcle-*-solaris*
+                       powerpcle-*-cygwin*
+                       powerpc-*-netware*
+                       w65-*-*
+                       i[3456]86-*-sunos*
+
+       o       clobber the files:
+
+                       configure.{in,host,tgt}
+                       Makefile.in
+                       *-tdep.c *-nat.c *-xdep.c
+                       configure/*/*
+
+       o       update NEWS
 
 --
 
-Delete macro TARGET_BYTE_ORDER_SELECTABLE.
+Change documentation to GFDL license.
 
-Patches in the database.
+``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?
+
+The GFDL and some instructions for using it can be found in
+http://www.gnu.org/copyleft/''
+
+       RMS
 
 --
 
@@ -213,37 +233,31 @@ http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00467.html
 
 --
 
-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.
 
 --
 
@@ -252,7 +266,8 @@ http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00845.html
 
 --
 
-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.
 
 --
 
@@ -261,7 +276,11 @@ Fix at least one thread bug.
 
 --
 
-Objective C/C++ Support.  Bu hopefully sooner...
+GCC 3.0 ABI support (but hopefully sooner...).
+
+--
+
+Objective C/C++ support (but hopefully sooner...).
 
 --
 
@@ -272,7 +291,17 @@ The following cleanups have been identified as part of GDB 5.2.
 
 --
 
-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
 
 --
 
@@ -288,6 +317,11 @@ See also sub-directory configure below.
 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
@@ -298,6 +332,60 @@ to any specific release.
 
 --
 
+Rename read_register{,_pid}() to read_unsigned_register{,_pid}().
+
+--
+
+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
@@ -366,17 +454,6 @@ needed.
 
 --
 
-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.
@@ -408,7 +485,7 @@ how.
 
 --
 
-Eliminate mmalloc() from GDB.
+Eliminate mmalloc(), mstrsave() et.al. from GDB.
 
 Also eliminate it from defs.h.
 
@@ -426,10 +503,6 @@ an error status.
 
 --
 
-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
 
@@ -529,6 +602,11 @@ 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
@@ -539,6 +617,26 @@ fundamental architectural change.
 
 --
 
+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.
 
@@ -622,7 +720,106 @@ limited number of hardwired actions.
 
 --
 
-Get the TUI working on all platforms.
+Fix TUI
+
+     o  readline/*.h bitrot
+
+        The TUI isn't up-to-date with
+        respect to the readline currently
+        bundled with GDB.  Importing a
+        new readline is on the 5.1 wish
+        list so this can only get worse.
+
+        Grep for things like term_cursor_move.
+
+        (To be honest, I don't see anyone
+        importing a new readline before 5.1 is
+        out)
+
+     o  tui.c:va_catch_errors() bitrot
+
+        This nasty piece of work used knowledge
+        of the internals of GDBs error functions :-(
+        Ever since those internals were cleaned
+        up this code has been broken. :-(
+
+     o  tuiWin.c:c_makeVisibleWithNewHeight() broken
+        tuiLayout.c:_extractDisplayStartAddr() broken
+
+        Both these function call find_line_pc()
+        incorrectly (wrong args, wrong return value).
+
+        I suspect this bug has always been there!
+        It had been hidden because those files
+        didn't include the necessary header files
+        from gdb proper :-(
+
+     o  tuiRegs() host dependant
+
+        Not suprisingly, this isn't a very portable
+        section of code.  However, I'm sure people
+        could live with no regs in the short to
+        medium term.
+
+     o  defs.h: #include "tui.h" et.al.
+
+        I'm not sure where this came from.
+        It was a really bad idea.
+
+        To get things to compile I did a nasty
+        hack (Just declare what was needed and
+        replace any expressions like xx->y.z()
+        in GDB proper with function calls).  I
+        could commit it slightly cleaned up if
+        you like.
+
+        Medium Term. the #ifdef TUI and TuiDo()
+        should be changed to hooks (like GDBTK).
+        The gdb-events.[hc] is there for that
+        purpose (1)
+
+     o  tui.c:_tuiReset() host dependant
+
+        tui.c contains a lump of termio[s]
+        I suspect an equivalent block of
+        code can be lifted from readline.
+        An equivalent readline function may
+        even be available.
+
+     o  curses.h vs ncurses.h.
+
+        Simple portability problem.
+
+     o  subsetCompare()
+
+        This function is a mystery - where is it?
+
+     o  tui-file.[hc] cleanup
+
+        This can be significantly simplified.
+
+     o  The code should be pacified. (-Werror -W...)
+
+        There are plenty of #includes,
+        duplicate #includes, missing function decls
+        and the like.
+
+        Some of the problems I found were through
+        fixing a few of the warnings.
+
+     o  The code should be GNUtified.
+
+        It would be very nice to have this code
+        look like the rest of GDB.  That way people
+        would be more accepting of it as a true
+        gdb component.
+
+        Until it is GNUtified it is going to stick
+        out like a sore thumb to the programmer.
+
+     o  The code should be clearly copyrighted
+
+        (FSF, with due credit to HP)
 
 --
 
@@ -719,19 +916,6 @@ Robert Lipe writes:
 > practical matter, the current thread support is somewhat more annoying
 > than when GDB was thread-unaware.
 
---
-
-Migrate qfThreadInfo packet -> qThreadInfo. (Andrew Cagney)
-
-Add support for packet enable/disable commands with these thread
-packets.  General cleanup.
-
-[PATCH] Document the ThreadInfo remote protocol queries
-http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00832.html
-
-[PATCH] "info threads" queries for remote.c
-http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00831.html
-
 --
 
                        Language Support
@@ -773,6 +957,32 @@ Get DEC/Compaq to contribute their Modula-3 support.
 
 --
 
+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.
+
+--
+
+Migrate qfThreadInfo packet -> qThreadInfo. (Andrew Cagney)
+
+Add support for packet enable/disable commands with these thread
+packets.  General cleanup.
+
+[PATCH] Document the ThreadInfo remote protocol queries
+http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00832.html
+
+[PATCH] "info threads" queries for remote.c
+http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00831.html
+
+--
+
 Remote protocol doco feedback.
 
 Too much feedback to mention needs to be merged in (901660).  Search
@@ -799,6 +1009,32 @@ fixed so that it builds on 16 bit machines.
 
 --
 
+Fix the ``!'' packet.
+
+JT reported that the existing targets do, in fact return ``OK'' so it
+is possible to merge remote and extended-remote targets.
+
+--
+
+Drop ``<address>'' from the [SsCc] packets.
+
+I don't think that GDB generates them so having it in the protocol is
+silly.
+
+--
+
+Fix doco on the ``q'' packet.
+
+It has evolved into a generic RPC.  The notes should reflect this and,
+perhaps, the ``Q'' packet can be deprecated.
+
+The doco should mention that ``OK'' is a valid packet response.
+
+The doco should explain why ``OK'' needs to be a valid packet
+response.
+
+--
+
 Add the cycle step command.
 
 http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00237.html
@@ -815,10 +1051,6 @@ on the fly - should it be returned in the ``T'' packet?
 Underlying problem is that the register file is target endian.  If the
 target endianess changes gdb doesn't know.
 
---
-
-Rename read_register{,_pid}() to read_unsigned_register{,_pid}().
-
 --
 
                        Symbol Support
This page took 0.042134 seconds and 4 git commands to generate.