98 lines
4.0 KiB
Plaintext
98 lines
4.0 KiB
Plaintext
|
|
Suggested projects for aspiring or current GDB hackers
|
|
======================================================
|
|
|
|
(You should probably chat with bug-gdb@cygnus.com to make sure that
|
|
no one else is doing the project you chose).
|
|
|
|
Rewrite proceed, wait_for_inferior, and normal_stop to clean them up.
|
|
Suggestions:
|
|
|
|
1) Make each test in wait_for_inferior a seperate subroutine
|
|
call.
|
|
2) Combine wait_for_inferior and normal_stop to clean up
|
|
communication via global variables.
|
|
3) See if you can find some way to clean up the global
|
|
variables that are used; possibly group them by data flow
|
|
and information content?
|
|
|
|
Work out some kind of way to allow running the inferior to be done as
|
|
a sub-execution of, eg. breakpoint command lists. Currently running
|
|
the inferior interupts any command list execution. This would require
|
|
some rewriting of wait_for_inferior & friends, and hence should
|
|
probably be done in concert with the above.
|
|
|
|
Add function arguments to gdb user defined functions.
|
|
|
|
Add convenience variables that refer to exec file, symbol file,
|
|
selected frame source file, selected frame function, selected frame
|
|
line number, etc.
|
|
|
|
Add a "suspend" subcommand of the "continue" command to suspend gdb
|
|
while continuing execution of the subprocess. Useful when you are
|
|
debugging servers and you want to dodge out and initiate a connection
|
|
to a server running under gdb.
|
|
|
|
Work out and implement a reasonably general mechanism for multi-threaded
|
|
processies. There are parts of one implemented in convex-dep.c, if
|
|
you want an example.
|
|
|
|
Add stab information to allow reasonable debugging of inline functions
|
|
(possibly they should show up on a stack backtrace? With a note
|
|
indicating that they weren't "real"?).
|
|
|
|
Implement support for specifying arbitrary locations of stack frames
|
|
(in practice, this usually requires specification of both the top and
|
|
bottom of the stack frame (fp and sp), since you *must* retrieve the
|
|
pc that was saved in the innermost frame).
|
|
|
|
Modify the naked "until" command to step until past the current source
|
|
line, rather than past the current pc value. This is tricky simply
|
|
because the low level routines have no way of specifying a multi-line
|
|
step range, and there is no way of saying "don't print stuff when we
|
|
stop" from above (otherwise could just call step many times).
|
|
|
|
Modify the handling of symbols grouped through BINCL/EINCL stabs to
|
|
allocate a partial symtab for each BINCL/EINCL grouping. This will
|
|
seriously decrease the size of inter-psymtab dependencies and hence
|
|
lessen the amount that needs to be read in when a new source file is
|
|
accessed.
|
|
|
|
Do an "x/i $pc" after each stepi or nexti.
|
|
|
|
Modify all of the disassemblers to use printf_filtered to get correct
|
|
more filtering.
|
|
|
|
Modify gdb to work correctly with Pascal.
|
|
|
|
Rewrite macros that handle frame chaining and frameless functions.
|
|
They should be able to tell the difference between start, main, and a
|
|
frameless function called from main.
|
|
|
|
Work out what information would need to be included in an executable
|
|
by the compiler to allow gdb to debug functions which do not have a
|
|
frame pointer. Modify gdb and gcc to do this.
|
|
|
|
When `attached' to a program (via either OS support or remote
|
|
debugging), gdb should arrange to catch signals which the terminal
|
|
might send, as it is unlikely that the program will be able to notice
|
|
them. SIGINT and SIGTSTP are obvious examples.
|
|
|
|
Enhance the gdb manual with extra examples where needed.
|
|
|
|
Arrange for list_command not to use decode_line_1 and thus not require
|
|
symbols to be read in simply to read a source file.
|
|
|
|
Allow patching of executables, a la "adb -w".
|
|
|
|
Improve the target interface so that targets can be stacked; e.g. an
|
|
exec file and a core file (memory references that the core file can't
|
|
satisfy are directed to the exec file); those two plus a child process.
|
|
The child doesn't let any refs through, but when the child terminates,
|
|
you are back to debugging the core file -- you might even want to swap
|
|
back and forth between the two, or between two core files.
|
|
|
|
# Local Variables:
|
|
# mode: text
|
|
# End:
|