1 If you find inaccuracies in this list, please send mail to
2 gdb-patches@sources.redhat.com. If you would like to work on any
3 of these, you should consider sending mail to the same address, to
4 find out whether anyone else is working on it.
10 Below is a list of problems identified during the GDB 5.0 release
11 cycle. People hope to have these problems fixed in 5.1.
15 Wow, three bug reports for the same problem in one day! We should
16 probably make fixing this a real priority :-).
18 Anyway, thanks for reporting.
20 The following patch will fix the problems with setting breakpoints in
21 dynamically loaded objects:
23 http://sources.redhat.com/ml/gdb-patches/2000-05/msg00230.html
25 This patch isn't checked in yet (ping Michael/JimB), but I hope this
26 will be in the next GDB release.
28 There should really be a test in the testsuite for this problem, since
29 it keeps coming up :-(. Any volunteers?
35 GDB 5.1 - New features
36 ======================
38 The following new features should be included in 5.1.
45 The following code cleanups will hopefully be applied to GDB 5.1.
49 GDB 5.1 - Known Problems
50 ========================
56 The z8k has suffered bit rot and is known to not build. The problem
57 was occuring in the opcodes directory.
61 The BFD directory requires bug-fixed AUTOMAKE et.al.
63 AUTOMAKE 1.4 incorrectly set the TEXINPUTS environment variable. It
64 contained the full path to texinfo.tex when it should have only
65 contained the directory. The bug has been fixed in the current
66 AUTOMAKE sources. Automake snapshots can be found in:
67 ftp://sources.redhat.com/pub/gdb/infrastructure
68 and ftp://sources.redhat.com/pub/binutils
72 Solaris 8 x86 CURSES_H problem
73 http://sources.redhat.com/ml/gdb/2000-07/msg00038.html
75 The original problem was worked around with:
77 2000-06-06 Michael Snyder <msnyder@cygnus.com>
79 * configure.in: Enable autoconf to find curses.h on Solaris 2.8.
80 * configure: Regenerate.
82 When building both GDB and SID using the same source tree the problem
83 will still occure. sid/component/configure.in mis-configures
84 <curses.h> and leaves wrong information in the config cache.
93 GDB 5.2 - New features
94 ======================
98 GCC 3.0 ABI support (but hopefully sooner...).
102 Objective C/C++ support (but hopefully sooner...).
106 Import of readline 4.2
113 The following cleanups have been identified as part of GDB 5.2.
119 Eliminate warnings for all targets on at least one host for one of the
120 -W flags. Flags up for debate include: -Wswitch -Wcomment -trigraphs
121 -Wtrigraphs -Wunused-function -Wunused-label -Wunused-variable
122 -Wunused-value -Wchar-subscripts -Wtraditional -Wshadow -Wcast-qual
123 -Wcast-align -Wwrite-strings -Wconversion -Wstrict-prototypes
124 -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls
125 -Woverloaded-virtual -Winline
129 Deprecate, if not delete, the following:
134 Replaced by, on the target side
136 and on core-gdb side:
137 {read,write}_register_gen()
138 Remote.c will need to use something
139 other than REGISTER_BYTE() and
140 REGISTER_RAW_SIZE() when unpacking
143 STORE_PSEUDO_REGISTER
144 FETCH_PSEUDO_REGISTER
145 Now handed by the methods
146 gdbarch_{read,write}_register()
147 which sits between core GDB and
151 REGISTER_CONVERT_TO_RAW
152 REGISTER_CONVERT_TO_VIRTUAL
153 I think these three are redundant.
154 gdbarch_register_{read,write} can
155 do any conversion it likes.
157 REGISTER_VIRTUAL_SIZE
158 MAX_REGISTER_VIRTUAL_SIZE
159 REGISTER_VIRTUAL_TYPE
160 I think these can be replaced by
162 FRAME_REGISTER_TYPE(frame, regnum)
163 REGISTER_TYPE(regnum)
167 FRAME_REGISTER_INFO (frame, ...)
170 If nothing else rename this so that
171 how it relates to rawreg and the
176 Obsolete the targets:
184 Obsolete the protocols:
188 ``As of version 5.3, WindRiver has removed the RDB server (RDB
189 protocol support is built into gdb).'' -- Till.
193 Restructure gdb directory tree so that it avoids any 8.3 and 14
198 Convert GDB build process to AUTOMAKE.
200 See also sub-directory configure below.
202 The current convention is (kind of) to use $(<header>_h) in all
203 dependency lists. It isn't done in a consistent way.
207 GDB 5.2 - Known Problems
208 ========================
212 Code Cleanups: General
213 ======================
215 The following are more general cleanups and fixes. They are not tied
216 to any specific release.
219 New Features and Fixes
220 ======================
222 These are harder than cleanups but easier than work involving
223 fundamental architectural change.
230 New languages come onto the scene all the time.
234 Re: Various C++ things
236 RTTI for g++ should be using the typeinfo functions rather than the
237 vtables. The typeinfo functions are always at offset 4 from the
238 beginning of the vtable, and are always right. The vtables will have
239 weird names like E::VB sometimes. The typeinfo function will always
240 be "E type_info function", or somesuch.
242 value_virtual_fn_field needs to be fixed so there are no failures for
243 virtual functions for C++ using g++.
245 Testsuite cases are the major priority right now for C++ support,
246 since i have to make a lot of changes that could potentially break
257 Investiagate ways of reducing memory.
261 Investigate ways of improving load time.
268 There are never to many testcases.
272 Better thread testsuite.
276 Better C++ testsuite.
280 Architectural Changes: General
281 ==============================
283 These are harder than simple cleanups / fixes and, consequently
284 involve more work. Typically an Architectural Change will be broken
285 down into a more digestible set of cleanups and fixes.
289 Architectural Change: Multi-arch et al.
290 =======================================
292 The long term objective is to remove all assumptions that there is a
293 single target with a single address space with a single instruction
294 set architecture and single application binary interface.
296 This is an ongoing effort. The first milestone is to enable
297 ``multi-arch'' where by all architectural decisions are made at
300 It should be noted that ``gdbarch'' is really ``gdbabi'' and
301 ``gdbisa''. Once things are multi-arched breaking that down correctly
302 will become much easier.
306 Architectural Change: MI, LIBGDB and scripting languages
307 ========================================================
309 See also architectural changes related to the event loop. LIBGDB
310 can't be finished until there is a generic event loop being used by
313 The long term objective is it to be possible to integrate GDB into
318 Architectural Change: Async
319 ===========================
321 While GDB uses an event loop when prompting the user for input. That
322 event loop is not exploited by targets when they allow the target
323 program to continue. Typically targets still block in (target_wait())
324 until the program again halts.
326 The closest a target comes to supporting full asynchronous mode are
327 the remote targets ``async'' and ``extended-async''.