|
|
Possible Future MDB EnhancementsThis page is a collection of random thoughts from those who have been working on MDB or participating in the discussion forums. These are non-trivial projects that range from the mundane to the completely insane. Before trying your hand at any of these projects, be sure to contact one of the community leaders for assistance. They are roughly ordered by degree of complexity. vi modeThis would create a separate CLI mode for vi compatbility (via "::set -o vi"). It would basically mimic the vi mode of your favorite shell. Prototypes of this exist; be sure to contact Eric Schrock if you're interested in this. The official BugID for this request is 4414259. Tab completionAnother CLI enhancement, this proposes to add simple tab completion to MDB. Pretty much the only thing we can safely do is symbol completion and dcmd/walker completion. Any attempt to tab-complete arguments would get pretty hairy pretty quickly. Conditional breakpointsMDB supports command execution on each breakpoint by which you can implement a poor man's conditional breakpoint, but it's complicated, and on KMDB results in the debugger repeatedly stopping and producing unnecessary output. It would be nice if this was a built in feature that didn't require so much extra work. CTF line number supportAdd basic line number information to CTF, so that we can do a first pass at source level debugging. This would not include advanced logic to display actual source, or necessarily step between lines of a source file. The most basic implementation would simply display disassembler annotated with the appropriate file and line information. Native DWARF/STABS supportA much more significant project, this would be a debug-format agnostic library that understood CTF as well as DWARF and STABS information. We would like to make the CTF tools an official supported tool shipped with Solaris (instead of a build companion tool), but it would be extremely convenient for external developers to not have to worry about this. The main requirement would be transparent access to type information, but could also include line number support to enable source level debugging. Source level debuggingThis would require one or both of the above projects to be implemented, and would build an infrastructure to get and display annotated source, well as step over individual lines, and get and set breakpoints based on source locations. Alternate grammar supportThe current MDB language is based around historical adb(1) compatability. This doesn't always translate into the most usable interface. It would be feasible to design a modular architecture such that the language interpreter could be changed on the fly to support more user-friendly modes. C comparison languageThe current libmdbThe nirvana of MDB development. Architect MDB in such a way that the bulk of the debugger logic lives inside a library. KMDB and MDB simply become consumers providing a thin veneer on top of this library coupled with a large set of module support. This would enable a whole host of possibilities, not the least of which is a GUI debugger. |