find out whether anyone else is working on it.
- Known problems in GDB 5.0
- =========================
+ GDB 5.1 - Fixes
+ ===============
Below is a list of problems identified during the GDB 5.0 release
-cycle. People hope to have these problems fixed in a follow-on
-release.
+cycle. People hope to have these problems fixed in 5.1.
--
-The BFD directory requires bug-fixed AUTOMAKE et.al.
+Hardware watchpint problems on x86 OSes, including Linux:
-AUTOMAKE 1.4 incorrectly set the TEXINPUTS environment variable. It
-contained the full path to texinfo.tex when it should have only
-contained the directory. The bug has been fixed in the current
-AUTOMAKE sources. Automake snapshots can be found in:
- ftp://sourceware.cygnus.com/pub/gdb/snapshots
-and ftp://sourceware.cygnus.com/pub/binutils
+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.)
--
x86 linux GDB and SIGALRM (???)
http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00803.html
-I know there are problems with single stepping through signal
-handlers. These problems were present in 4.18. They were just masked
-because 4.18 failed to recognize signal handlers. Fixing it is not
-easy, and will require changes to handle_inferior_event(), that I
-prefer not to make before the 5.0 release.
+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
--
-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.
-
---
-
Can't build IRIX -> arm GDB.
http://sourceware.cygnus.com/ml/gdb-patches/2000-04/msg00356.html
> stoping in weak functions.
>
> It stops in a function that is defined as weak, not in the function
-> that is actualy run...
+> that is actually run...
--
--
- Code Cleanups: Next Release
- ===========================
+Thread support. Right now, as soon as a thread finishes and exits,
+you're hosed. This problem is reported once a week or so.
+
+--
+
+Wow, three bug reports for the same problem in one day! We should
+probably make fixing this a real priority :-).
+
+Anyway, thanks for reporting.
+
+The following patch will fix the problems with setting breakpoints in
+dynamically loaded objects:
+
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00230.html
+
+This patch isn't checked in yet (ping Michael/JimB), but I hope this
+will be in the next GDB release.
+
+There should really be a test in the testsuite for this problem, since
+it keeps coming up :-(. Any volunteers?
+
+Mark
+
+--
+
+Re: GDB 5.0.1?
+http://sources.redhat.com/ml/gdb/2000-07/msg00038.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.
+
+Simply editing the config.h to define CURSES_H fixes the problem, and
+then the build works fine.
+
+The status for this problem:
+
+Solaris 8 x86 (PIII-560)
+gcc 2.95.2
+
+I had the same problem with several of the snapshots shortly before
+5.0 became official, and 5.0 has the same problem.
+
+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.
+
+Mike
+
+--
+
+ GDB 5.1 - New features
+ ======================
+
+The following new features should be included in 5.1.
+
+--
+
+Enable MI by default. Old code can be deleted after 5.1 is out.
+
+--
+
+Pascal (Pierre Muller, David Taylor)
+
+Pierre Muller has contributed patches for adding Pascal Language
+support to GDB.
+
+2 pascal language patches inserted in database
+http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00521.html
+
+Indent -gnu ?
+http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00496.html
+
+--
+
+Java (Anthony Green, David Taylor)
+
+Anthony Green has a number of Java patches that did not make it into
+the 5.0 release. The first two are in cvs now, but the third needs
+some fixing up before it can go in.
+
+Patch: java tests
+http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00512.html
+
+Patch: java booleans
+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
+
+--
+
+[Comming...]
+
+Modify gdb to work correctly with Pascal.
+
+--
+
+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.
+
+--
+
+ GDB 5.1 - Cleanups
+ ==================
+
+The following code cleanups will hopefully be applied to GDB 5.1.
-The following are small cleanups that will hopefully be completed by
-the follow on to 5.0.
+--
+
+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?
+
+The GFDL and some instructions for using it can be found in
+http://www.gnu.org/copyleft/''
+
+ RMS
--
--
+Fix copyright notices.
+
+Turns out that ``1998-2000'' isn't considered valid :-(
+
+http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00467.html
+
+--
+
Purge PARAMS.
Eliminate all uses of PARAMS in GDB's source code.
--
-Elimination of make_cleanup_func. (Andrew Cagney)
+printcmd.c (print_address_numeric):
-make_cleanup_func elimination
-http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00791.html
-http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00814.html
+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?
--
-Fix copyright notices.
+Compiler warnings.
-Turns out that ``1998-2000'' isn't considered valid :-(
+Eliminate all warnings for at least one host/target for the flags:
+-Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses
+-Wpointer-arith -Wuninitialized
-http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00467.html
+--
+
+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
+
+--
+
+ GDB 5.2 - Fixes
+ ===============
+
+--
+
+Fix at least one thread bug.
+
+--
+
+ GDB 5.2 - New features
+ ======================
+
+--
+
+Objective C/C++ Support. Bu hopefully sooner...
+
+--
+
+ GDB 5.2 - Cleanups
+ ==================
+
+The following cleanups have been identified as part of GDB 5.2.
+
+--
+
+Eliminate more compiler warnings.
+
+--
+
+Restructure gdb directory tree so that it avoids any 8.3 and 14
+filename problems.
+
+--
+
+Convert GDB build process to AUTOMAKE.
+
+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.
--
--
+The BFD directory requires bug-fixed AUTOMAKE et.al.
+
+AUTOMAKE 1.4 incorrectly set the TEXINPUTS environment variable. It
+contained the full path to texinfo.tex when it should have only
+contained the directory. The bug has been fixed in the current
+AUTOMAKE sources. Automake snapshots can be found in:
+ ftp://sourceware.cygnus.com/pub/gdb/snapshots
+and ftp://sourceware.cygnus.com/pub/binutils
+
+--
+
+Find something better than DEFAULT_BFD_ARCH, DEFAULT_BFD_VEC to
+determine the default isa/byte-order.
+
+--
+
+Rely on BFD_BIG_ENDIAN and BFD_LITTLE_ENDIAN instead of host dependent
+BIG_ENDIAN and LITTLE_ENDIAN.
+
+--
+
Eliminate more compiler warnings.
Of course there also needs to be the usual debate over which warnings
Elimination of ``(catch_errors_ftype *) func''.
Like make_cleanup_func it isn't portable.
+http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00791.html
+http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00814.html
+
+--
+
+Nuke #define CONST_PTR.
--
--
-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().
--
--
+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
--
-Updated readline
-
-Readline 4.? is out. A merge wouldn't hurt. Patches are in:
-
-http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00436.html
-
---
-
Deprecate "fg". Apparently ``fg'' is actually continue.
http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00417.html
--
-Always build ser-tcp.c.
+The ``maintenance deprecate set endian big'' command doesn't notice
+that it is deprecating ``set endian'' and not ``set endian big'' (big
+is implemented using an enum). Is anyone going to notice this?
+
+--
-The patch as submitted was just going to add ser-tcp.c to the Alpha's
-makefile. A better patch is to instead add ser-tcp.c to SER_HARDWARE
-and make it a standard part of all debuggers.
+When tab expanding something like ``set arch<tab>'' ignore the
+deprecated ``set archdebug'' and expand to ``set architecture''.
-If problems occure then configure.in can sort them out.
+--
-http://sourceware.cygnus.com/ml/gdb-patches/2000-04/msg00544.html
+Eliminate ``arm_register_names[j] = (char *) regnames[j]'' and the
+like from arm-tdep.c.
--
-Follow through `make check' with --enable-shared.
+Fix uses of ->function.cfunc = set_function().
-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.
+The command.c code calls sfunc() when a set command. Rather than
+change it suggest fixing the callback function so that it is more
+useful. See:
-http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00845.html
+http://sourceware.cygnus.com/ml/gdb-patches/2000-06/msg00062.html
+
+See also ``Fix implementation of ``target xxx''.'' below.
--
-Change the parameter ``char *list[]'' (etc) to ``const char (*)[]'' so
-that dynamic lists from things like gdbarch_printable_names() can be
-passed.
+IRIX 3.x support is probably broken.
--
-The ``maintenance deprecate set endian big'' command doesn't notice
-that it is deprecating ``set endian'' and not ``set endian big'' (big
-is implemented using an enum). Is anyone going to notice this?
+Delete sim/SIM_HAVE_BREAKPOINTS and gdb/SIM_HAS_BREAKPOINTS.
+http://sourceware.cygnus.com/ml/gdb-patches/2000-07/msg00042.html
+
+Apart from the d30v, are there any sim/common simulators that make use
+of this?
+
+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).
--
-When tab expanding something like ``set arch<tab>'' ignore the
-deprecated ``set archdebug'' and expand to ``set architecture''.
+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).
+
+--
New Features and Fixes
======================
Add built-by, build-date, tm, xm, nm and anything else into gdb binary
so that you can see how the GDB was created.
-Some of these (*m.h) would be added to the generated config.h. That
-in turn would fix a long standing bug where by the build process many
-not notice a changed tm.h file. Since everything depends on config.h,
-a change to *m.h forces a change to config.h and, consequently forces
-a rebuild.
-
--
Add an "info bfd" command that displays supported object formats,
--
-Convert GDB build process to AUTOMAKE.
-
-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.
+Add support for:
+
+(gdb) p fwprintf(stdout,L"%S\n", f)
+No symbol "L" in current context.
--
--
-Restructure gdb directory tree so that it avoids any 8.3 and 14
-filename problems.
-
---
-
Add a transcript mechanism to GDB.
Such a mechanism might log all gdb input and output to a file in a
Update texinfo.tex to latest?
-
-
--
Incorporate agentexpr.texi into gdb.texinfo
``(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
--
-Pascal (Pierre Muller, David Taylor)
-
-Pierre Muller has contributed patches for adding Pascal Language
-support to GDB.
-
-2 pascal language patches inserted in database
-http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00521.html
-
-Indent -gnu ?
-http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00496.html
-
---
-
-Java (Anthony Green, David Taylor)
-
-Anthony Green has a number of Java patches that did not make it into
-the 5.0 release.
-
-Patch: java tests
-http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00512.html
-
-Patch: java booleans
-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
-
---
-
-[Comming...]
-
-Modify gdb to work correctly with Pascal.
-
---
-
Re: Various C++ things
value_headof/value_from_vtable_info are worthless, and should be
--
-set/show remote X-packet ...
-
-``(gdb) help set remote X-packet'' doesn't list the applicable
-responses. The help message needs to be expanded.
-
---
-
Remote protocol doco feedback.
Too much feedback to mention needs to be merged in (901660). Search
fixing this this is making GDB's remote protocol packet more robust.
While downloading to a remote protocol target, gdb ignores packet
-errors in so far as it will continue to edownload with chunk N+1 even
+errors in so far as it will continue to download with chunk N+1 even
if chunk N was not correctly sent. This causes gdb.base/remote.exp to
take a painfully long time to run. As a PS that test needs to be
fixed so that it builds on 16 bit machines.
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
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
Consequence of recent symtab clarification. No marks for figuring out
who maintains the MIPS.
+--
+
+GDB truncates 64 bit enums.
+
+http://sourceware.cygnus.com/ml/gdb-patches/2000-06/msg00290.html
+
--
Testsuite Support
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 MIPS pure multi-arch.
+
+It is only at the multi-arch enabled stage.
+
+--
+
Truly multi-arch.
Enable the code to recognize --enable-targets=.... like BINUTILS does.
--
-Make MI interface accessable from existing CLI.
+Make MI interface accessible from existing CLI.
--
handles the correct output well. It doesn't resolve what to do with
output / error-messages when things go wrong.
+--
+
+do_setshow_command contains a 1024 byte buffer.
+
+The function assumes that there will never be any more than 1024 bytes
+of enum. It should use mem_file.
+
+--
+
+Should struct cmd_list_element . completer take the command as an
+argument?
+
+--
+
+Should the bulk of top.c:line_completion_function() be moved to
+command.[hc]? complete_on_cmdlist() and complete_on_enums() could
+then be made private.
+
+--
+
+top.c (execute_command): Should a command being valid when the target
+is running be made an attribute (predicate) to the command rather than
+an explicit set of tests.
+
+--
+
+top.c (execute_command): Should the bulk of this function be moved
+into command.[hc] so that top.c doesn't grub around in the command
+internals?
+
--
Architectural Change: Async
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.
for that command. Other changes such as making ``struct command''
opaque may also help.
+See also:
+http://sourceware.cygnus.com/ml/gdb-patches/2000-06/msg00062.html
+
--
Make "target xxx" command interruptible.