Possible Future MDB Enhancements
This 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 mode
This 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 completion
Another 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 breakpoints
MDB 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 support
Add 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 support
A 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 debugging
This 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 support
The 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 language
The current ::grep implementation is severely limited in what it can
accomplish. A more complete solution would leverage a more advanced compiler
(possibly the D compiler) to create a more complete language for conditional
comparison. The idea would be something like ::walk proc | ::dgrep ((proc_t *).)->p_user.u_comm == "ls".
libmdb
The 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.