In past comments, it has been pointed out that a transition guide between GDB and MDB would be useful to some developers out there. A full comparison would also cover dbx(1), but I'll defer this to a later point. Given the number of available commands, I'll be dividing up this post into at least two pieces.
Before diving into too much detail, it should be noted that MDB and GDB have slightly different design goals. MDB (and KMDB) replaced the aging adb(1) and crash(1M), and was designed primarily for post-mortem analysis and live kernel analysis. To this end, MDB presents the same interface when debugging a crash dump as when examining a live kernel. Solaris corefiles have been enhanced so that all the information for the process (including library text and type information) is present in the corefile. MDB can examine and run live processes, but lacks some of the features (source level debugging, STABS/DWARF support, conditional breakpoints, scripting language) that are standard for developer-centric tools like GDB (or dbx). GDB was designed for interactive process debugging. While you can use GDB on corefiles (and even LKCD crash dumps or Linux kernels - locally and remotely), you often need the original object files to take advantage of GDB's features.
Before going too far into MDB, be sure to check out Jonathan's MDB Cheatsheet as a useful quick reference guide, with some examples of stringing together commands into pipelines. Seeing as how I'm not the most accomplished GDB user in the world, I'll be basing this comparison off the equivalent GDB reference card.
|gdb program||mdb path|
mdb -p pid
|Start debugging a command or running process. GDB will treat numeric arguments as pids, while mdb explicitly requires the '-p' option|
|gdb program core||mdb [ program ] core||Debug a corefile associated with 'program'. For MDB, the program is optional and is generally unnecessary given the corefile enhancements made during Solaris 10.|
|quit||::quit||Both programs also exit on Ctrl-D.|
|In mdb, you can list all the available walkers or dcmds, as well as get help on a specific dcmd. Another useful trick is ::dmods -l module which lists walkers and dcmds provided by a specific module.|
|run arglist||::run arglist||Runs the program with the given arguments. If the target is currently running, or is a corefile, MDB will restart the program if possible.|
|kill||::kill||valign=top>Forcibly kill and release target.|
|show env||valign=top>::getenv||Display current environment.|
|set env var string||::setenv var=string||Set an environment variable.|
|get env var||valign=top>::getenv var||Get a specific environment variable.|
|Execute the given shell command.|
Breakpoints and Watchpoints
|valign=top>addr::bp||Set a breakpoint at the given|
address or function.
|break file:line||valign=top>-||Break at the given line of the file. MDB does not|
support source level debugging.
|break ... if expr||valign=top>-||Set a conditional breakpoint. MDB doesn't support|
conditional breakpoints, though you can get a close approximation via the
-c option (though its complicated enough to warrant its own
|watch expr||valign=top>addr::wp -rwx [-L size]||valign=top>|
|valign=top>::events||Display active watchpoints|
and breakpoints. MDB will show you signal events as well.
|delete [n]||valign=top>::delete n||Delete the given breakpoint or|
I think that's enough for now; hopefully the table is at least readable. More to come in a future post.