how to get as much as possible from dbx

Question

I do TDD on a daily basis for my C++ development on Solaris10. It has greatly reduced the time I have to spend using my debugger but sometime this is the only option.

DBX is pretty powerful but not that user friendly. Note that I'm talking about console DBX not the SunStudio GUI for DBX).

What are the best productivity tips you can give for dbx C++ debugging?

PS. Changing debugger is not an option.

Answer 1

I have bookmarked a few sites related to dbx. Here they are, in no particular order in case they might be useful to you:

• Why Can't dbx Find My Function?
• Online Help for the Dbx Debugger
• Sun Studio: debugging a multi-threaded application w/ dbx
• gdb vs. dbx: commands mapping and feature comparison
• Importing debug information into dbx
• command line dbx : See more source
• Sun Studio C++ - Your .dbxrc (NB: adapt the integer type used to cast pointers according to your pointer size)
• Sun Studio: Investigating memory leaks with dbx
• Sun Studio: Gathering memory allocations/leaks data, from a running process

EDIT on 2012 july 19th: I've tried to fix several link since Chris Quenelle's blog has moved. Some articles can still be accessed thanks to the wayback machine.

Answer 2

One of the powerful features of dbx is the built in ksh. You can write shell functions that are as complex as you might want to print customized views of data structures, or follow pointers in a specific route. The shell is an old variation of pdksh, so it's not the nicest for programming, but it's much better than not having any built-in language to use. There is also extensive help available from the command line. One trick for searching the help is to use "vi $helpfile" from within the dbx command shell. Tha tedits the raw helpfile data in one large file. You can see some examples of shell functions in the dbxrc file that ships with dbx and is loaded by default. You can see a more sophisticated example by looking at the libumem integration module. You can find it here:

http://quenelle.org/sun%20tech/2007/using-dbx-and-libumem.html

Answer 3

I too have to use dbx at work and understand your frustrations!

A few tips I have discovered which make my life a little easier:

Using the built commands system like this: when stop { print whatever ; }
Obviously doesn't work when whatever is out of scope, but I find it useful enough. I have yet to have much joy with the 'trace' facility, YMMV.

Making your own .dbxrc file makes life much easier, as does the "pathmap" feature.

Finally, this is only obvious if you know it already, but try Sun's manual.

It isn't particularly well written, but still an essential read.

Answer 4

Thanks to Luc Hermitte! Here is an updated version of his links and a few others.

• Why Can't dbx Find My Function?
• Sun Studio: debugging a multi-threaded application w/ dbx
• Importing debug information into dbx
• command line dbx : See more source
• Sun Studio: Investigating memory leaks with dbx
• Sun Studio: Gathering memory allocations/leaks data, from a running process
• Memory Leak Checking with libumem (if you are using dbx you might want to know about libumem)
• Using dbx with libumem (substantial dbx script example)
• How to use counts with breakpoints
• Adding automatic pretty-printers to dbx
• Oracle: Getting Started with dbx 12.3
• Oracle: dbx Manual 12.2

Additional tips:

• dbx has a ksh shell built in, so you can build powerful customized functions.
• You can get simple tracing with something like:
  • when at foo.cc:35 { print varname; }
• view all of the online help using: vi $helpfile