KDbg - A Graphical Debugger Interface

If you like KDbg, please go here.

Tips & Tricks

Displaying variable values in different formats
Setting breakpoints in dynamically loaded modules
Remote debugging

For more tips see the online documentation.

Displaying variable values in different formats

You can use gdb's format specifiers for displaying values in the expression watch window in different formats. Just prefix the expression to display by the format specifier. Example: /x foo->bar will display the value of foo->bar in hexadecimal notation. Here is a list of gdb's format specifiers:

/x	hexadecimal
/o	octal
/d	decimal
/u	unsigned decimal
/t	binary
/f	float
/a	address
/i	instruction
/c	char
/s	string

Setting breakpoints in dynamically loaded modules

The problem with dynamically loaded modules is that the debugger doesn't know about the symbol information until the module has been loaded by dlopen(). This is extremely annoying if you want to debug constructors that are run for static variables. The following trick works on systems that use glibc2.

Set a breakpoint that the program will hit before it loads the dynamic module, e.g. in main.
Run the program until it stops at this breakpoint.
Now you can set a breakpoint in the function _dl_debug_state. For this, open the breakpoint list (View|Breakpoints), Type _dl_debug_state in the edit box and click Add.
Continue the program until it stops at this breakpoint, which happens somewhere inside dlopen()! At this time, the symbols of the dynamic module are already available, but the constructors are not yet executed.
Now you can set a breakpoint in your constructor.

Be prepared that the breakpoint at _dl_debug_state will be hit several times while dlopen() does its work.

Note that the orphaned breakpoints feature does not really help. The reason is that orphaned breakpoints are not tried to be installed until the program stops. For this reason it is still required to set the breakpoint in _dl_debug_state. However, the breakpoints are preserved and can be set at any time, even before the program starts.

Remote debugging

There's a hack so you can do remote debugging. Invoke kdbg like this:

kdbg -r /dev/ttya proggy

Then KDbg issues the following gdb commands, in effect, it allows you to debug a remote target:

target remote /dev/ttya
file proggy

As you see, you could also do remote debugging through TCP/IP connection like this:

kdbg -r flaky:12345 proggy

assuming host flaky is running gdbserver with proggy on port 12345.

Note that you can set a program specific gdb command using the Settings|This Program menu.

Last modified May 02, 2006.

You are visitor number

since February 21, 2001. Thank you!