1 This is a list of things that theoretically should be possible in some
2 way or another. No commitment to actually do these, but these sound
3 possible to me right now. In no particular order. If someone else
4 wants to dig in, feel free.
6 1) Some kind of watchpoint capability. Pretty easy once we have a
7 single step capability, but we end up running the program
8 really slowly one instruction at a time. Use hardware debug
11 2) Some kind of .wdbinit file.
13 3) Add 'info line' command. Not all *that* useful, but it would tell you
14 the range of PC for a given source line.
16 4) Add search directory list for PDB files. We have the path in the
17 DOS notation (i.e. C:\foo\bar\xxx.c), which may be a useful hint.
20 5) Add support for emacs mode so that you can run under emacs and have
21 the source pop up automatically. Only useful once the list command
24 6 Add support for Borland. I have heard rumors that Borland is forthcoming
25 with info about how their stuff works, so this might not be that
28 7 Add support for Win16. Not sure if this is really worth the trouble. How
29 much are people really going to use this in the long run???
31 8) Some of the newer displays are still a little bit sparse on information.
32 Make these more like gdb.
34 9) Don't bother to disassemble an instruction when we stop at a breakpoint
35 and if we have a valid source line we are displaying.
37 10) Add support for '/i', etc in display command. Make sure 'display/i $eip'
38 does the correct thing, and then skip automatic disassembly completely.
40 11) Limit amount of information displayed with print command.
42 12) Make sure operator precedence works OK.