So talking to Ben last night convinced me I needed to finish up the GDB to MDB reference that I started last month. So here’s part two.
| GDB | MDB | Description | |
|---|---|---|---|
Program Stack |
|||
| backtrace n | ::stack $C |
Display stack backtrace for the current thread | |
| – | thread::findstack -v |
Display a stack for a given thread. In the kernel, thread is the address of the kthread_t. In userland, it's the thread identifier. |
|
| info ... | - | Display information about the current frame. MDB doesn't support the debugging data necessary to maintain the frame abstraction. |
|
Execution Control |
|||
| continue c |
:c | Continue target. | |
| stepi si |
::step ] |
Step to the next machine instruction. MDB does not support stepping by source lines. |
|
| nexti ni |
::step over [ |
Step over the next machine instruction, skipping any function calls. |
|
| finish | ::step out |
Continue until returning from the current frame. | |
| jump *address | address>reg | Jump to the given location. In MDB, reg depends on your platform. For SPARC it's 'pc', for i386 its 'eip', and for amd64 it's 'rip'. |
|
Display |
|||
| print expr | addr::print expr |
Print the given expression. In GDB you can specify variable names as well as addresses. For MDB, you give a particular address and then specify the type to display (which can include dereferencing of members, etc). |
|
| print /f | addr/f | Print data in a precise format. See ::formats for a list of MDB formats. |
|
| disassem addr | addr::dis | Dissasemble text at the given address, or the current PC if no address is specified |
|
This is just a primer. Both programs support a wide variety of additional
options. Running 'mdb -k', you can quickly see just how many commands are out
there:
> ::dcmds ! wc -l 385 > ::walkers ! wc -l 436
One helpful trick is ::dcmds ! grep thing, which searches the
description of each command. Good luck, and join the discussion over at the
OpenSolaris MDB
community if you have any questions or tips of your own.
Technorati tag: MDB
Technorati tag: OpenSolaris
Technorati tag: Solaris
2 Responses
Gosh, based on that primer one would think gdb is clearly a better choice. Twice you had to say that mdb just couldn’t do something gdb did — and they were pretty major things like looking at your frame and stepping by source line…
And the commands for mdb are pretty esoteric. Why is step prefixed by two colons but continue by one? What’s the logic spelling bracktrace “$C”?
Anonymous coward –
As has been mentioned many times before, MDB is not a source level debugger because it was not the design center. The things I mentioned above are things MDB can’t do because we can’t do source level debugging. But we’re also orders of magnitude ahead of GDB in terms of post mortem debugging and kernel debugging. So MDB is not the right tool for every job, it’s better at some things and GDB is better at others.
As for the language, it’s a necessary complication do to historical reasons: compatibility with adb(1). I should have noted that ‘$C’ (the old adb version) can be replaced by ‘::stack’ to be more modern. See the OpenSolaris community for more possible enhancements and further discussion.