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: