| 1 | |
| 2 | Suggested projects for aspiring or current GDB hackers |
| 3 | ====================================================== |
| 4 | |
| 5 | (You should probably chat with kingdon@ai.mit.edu to make sure that |
| 6 | no one else is doing the project you chose). |
| 7 | |
| 8 | Add watchpoints (break if a memory location changes). This would |
| 9 | usually have to involve constant single stepping, but occasionally |
| 10 | there is operating system support which gdb should be able to cleanly |
| 11 | use (e.g. on the 80386, there are 4 debug registers. By ptracing an |
| 12 | address into them, you can get a trap on writes or on reads and |
| 13 | writes). |
| 14 | |
| 15 | Rewrite proceed, wait_for_inferior, and normal_stop to clean them up. |
| 16 | Suggestions: |
| 17 | |
| 18 | 1) Make each test in wait_for_inferior a seperate subroutine |
| 19 | call. |
| 20 | 2) Combine wait_for_inferior and normal_stop to clean up |
| 21 | communication via global variables. |
| 22 | 3) See if you can find some way to clean up the global |
| 23 | variables that are used; possibly group them by data flow |
| 24 | and information content? |
| 25 | |
| 26 | Work out some kind of way to allow running the inferior to be done as |
| 27 | a sub-execution of, eg. breakpoint command lists. Currently running |
| 28 | the inferior interupts any command list execution. This would require |
| 29 | some rewriting of wait_for_inferior & friends, and hence should |
| 30 | probably be done in concert with the above. |
| 31 | |
| 32 | Add function arguments to gdb user defined functions. |
| 33 | |
| 34 | Add convenience variables that refer to exec file, symbol file, |
| 35 | selected frame source file, selected frame function, selected frame |
| 36 | line number, etc. |
| 37 | |
| 38 | Add a "suspend" subcommand of the "continue" command to suspend gdb |
| 39 | while continuing execution of the subprocess. Useful when you are |
| 40 | debugging servers and you want to dodge out and initiate a connection |
| 41 | to a server running under gdb. |
| 42 | |
| 43 | Make "handle" understand symbolic signal names. |
| 44 | |
| 45 | Work out and implement a reasonably general mechanism for multi-threaded |
| 46 | processies. There are parts of one implemented in convex-dep.c, if |
| 47 | you want an example. |
| 48 | |
| 49 | A standalone version of gdb on the i386 exists. Anyone who wants to |
| 50 | do some serious working cleaning it up and making it a general |
| 51 | standalone gdb should contact pace@wheaties.ai.mit.edu. |
| 52 | |
| 53 | Add stab information to allow reasonable debugging of inline functions |
| 54 | (possibly they should show up on a stack backtrace? With a note |
| 55 | indicating that they weren't "real"?). |
| 56 | |
| 57 | Implement support for specifying arbitrary locations of stack frames |
| 58 | (in practice, this usually requires specification of both the top and |
| 59 | bottom of the stack frame (fp and sp), since you *must* retrieve the |
| 60 | pc that was saved in the innermost frame). |
| 61 | |
| 62 | Modify the naked "until" command to step until past the current source |
| 63 | line, rather than past the current pc value. This is tricky simply |
| 64 | because the low level routines have no way of specifying a multi-line |
| 65 | step range, and there is no way of saying "don't print stuff when we |
| 66 | stop" from above (otherwise could just call step many times). |
| 67 | |
| 68 | Modify the handling of symbols grouped through BINCL/EINCL stabs to |
| 69 | allocate a partial symtab for each BINCL/EINCL grouping. This will |
| 70 | seriously decrease the size of inter-psymtab dependencies and hence |
| 71 | lessen the amount that needs to be read in when a new source file is |
| 72 | accessed. |
| 73 | |
| 74 | Work out some method of saving breakpoints across the reloading of an |
| 75 | executable. Probably this should be by saving the commands by which |
| 76 | the breakpoints were set and re-executing them (as text locations may |
| 77 | change). |
| 78 | |
| 79 | Do an "x/i $pc" after each stepi or nexti. |
| 80 | |
| 81 | Modify all of the disassemblers to use printf_filtered to get correct |
| 82 | more filtering. |
| 83 | |
| 84 | Modify gdb to work correctly with Pascal. |
| 85 | |
| 86 | Rewrite macros that handle frame chaining and frameless functions. |
| 87 | They should be able to tell the difference between start, main, and a |
| 88 | frameless function called from main. |
| 89 | |
| 90 | Work out what information would need to be included in an executable |
| 91 | by the compiler to allow gdb to debug functions which do not have a |
| 92 | frame pointer. Modify gdb and gcc to do this. |
| 93 | |
| 94 | When `attached' to a program (via either OS support or remote |
| 95 | debugging), gdb should arrange to catch signals which the terminal |
| 96 | might send, as it is unlikely that the program will be able to notice |
| 97 | them. SIGINT and SIGTSTP are obvious examples. |
| 98 | |
| 99 | Enhance the gdb manual with extra examples where needed. |
| 100 | |
| 101 | Arrange for list_command not to use decode_line_1 and thus not require |
| 102 | symbols to be read in simply to read a source file. |
| 103 | |
| 104 | Problem in xgdb; the readline library needs the terminal in CBREAK |
| 105 | mode for command line editing, but this makes it difficult to dispatch |
| 106 | on button presses. Possible solution: use a define to replace getc in |
| 107 | readline.c with a routine that does button dispatches. You should |
| 108 | probably see XGDB-README before you fiddle with XGDB. Also, someone |
| 109 | is implementing a new xgdb; it may not be worth while fiddling with |
| 110 | the old one. |
| 111 | |
| 112 | # Local Variables: |
| 113 | # mode: text |
| 114 | # End: |