First of all, compile with debug information (switch -g). Don't use optimization without need, debugging might become confusing. Also note that gdb/mi is not compatible with all gdb/console commands. This means that .gdbinit files in your home directory or the application directory may cause problems if they contain incompatible commands.
If possible, you should use at least gdb 6.8. Beginning with this version gdb/mi supports setting (pending) breakpoints in shared libraries not loaded yet, and more reliable breakpoints in constructors.
If some or all binaries have been compiled on another machine within another source file directory tree, then gdb and ccdebug cannot find the source files. Starting with version 6.7 you may use the gdb command "set substitute-path" to define a source path substitution rule.
If there are source files with identical name (from different shared libraries), it may be difficult for gdb and ccdebug to load the correct file. In that case the best solution is to rename a file and recompile the shared library. If this isn't feasible, you may try to assign a higher priority to a source file by clicking onto the "Prefer" button in the source files dialog (Alt-Ctl-F).
Breakpoint data are stored in the XML-file .ccdebugDbg in your home directory.
When an application is started again in ccdebug, then ccdebug tries to set the
This will fail for breakpoints in shared libraries, as long as the library
is not loaded yet. However, gdb versions newer than gdb6.8 keep a list
of pending breakpoints and try to set them when a shared library was loaded.
Hint: Use absolute file pathnames to set breakpoints. To achieve this open the source file with the file dialog (Ctl-O), locate the line and press F9.
For older gdb versions there is some automatism in ccdebug: ccdebug retries to set the breakpoints every time gdb stops.
Source files from shared libraries are only available when the shared library
has been loaded. To see the files in the source files dialog (Alt-Ctl-F), the
button "Update" must be pressed. Header files (*.h) are only listed when the
"Show header files" check is set.
To locate some shared library source file you might set a
breakpoint at the position where the shared library gets loaded.
Gdb normally loads the shared library symbols automatically. In special circumstances this may be done explicitely with the gdb command "share" (Alt-Ctl-G).
Signal handling may be specified in the "Signals" dialog. To completely ignore a signal you may uncheck "Stop", "Print" and "Pass". To completely disable a signal each time the session is started you may enter a line "handle <sigName>" in the "Pragma" text field of the "Session" dialog, where <sigName> is the signal name (for instance SIG32).
To display user defined data types in a specific way in the popup window, add the function printUsrDefType() to your ~/.gdbinit file, and insert the desired printf() statements. This function gets called from ccdebug when the cursor is above a variable name in the editor window. $arg0 is the data type name, $arg1 is the expression to evaluate. To get started you might simply copy the ~/.gdbinit from the ccdebug directory to your home directory (if this wasn't done during installation).
#printUsrDefType. arg0 is the typeName, arg1 is the expr// define printUsrDefType __strcmp $arg0 "CMyType1" if $match printf "printUsrDefType(CMyType1) says: %d\n", $arg1.val end __strcmp $arg0 "CMyType2" if $match printf "printUsrDefType(CMyType2) says: %d\n", $arg1.val end #ToDo for your types: Add __strcmp statements and corresponding if-end blocks doing the printf() endFor this to work the string compare function __strcmp() also must be added to your ~/.gdbinit file:
#From Ira L. Ruben, gdbinit-MacsBug-without-plugin// define __strcmp set $__s1 = (unsigned char*)($arg0) set $__s2 = (unsigned char*)($arg1) set $match = 1 set $__c1 = *((unsigned char*)$__s1)++ while ($match && $__c1) set $__c2 = *((unsigned char*)$__s2)++ if ($__c1 == $__c2) set $__c1 = *((unsigned char*)$__s1)++ else set $match = 0 end end set $match &= (*(unsigned char*)$__s2 == 0) endIf ccdebug doesn't find the printUsrDefType function, in the case of QStrings it then tries to call pqs, which should print the Qt4 (or Qt3) QString.
To interrupt program execution when a C++ exception gets thrown enter "catch throw" in the gdb window (Alt-Ctl-G).
To interrupt program execution when a C++ exception gets catched enter "catch catch" in the gdb window (Alt-Ctl-G).
If your application is linked against another Qt version than ccdebug, then depending on
the environment variable LD_LIBRARY_PATH ccdebug or the application might not start. Simply passing the
correct LD_LIBRARY_PATH to gdb doesn't solve the problem.
A workaround is to start the application from the command line and to "Attach"
ccdebug to the running application.
A better solution is to specify a shell script as "gdb" in the "Session" dialog's "Pragma" field by adding a line "gdb <PathnameOfScript>". The script should set LD_LIBRARY_PATH and other variables and then start gdb, for example
#!/bin/sh #Description: Sets environment for program to debug and starts gdb. export LD_LIBRARY_PATH=.:/extraQt/lib: <PathToGdb>/gdb "$@"
Specify an "Executable" (with debug information) in the "Debug Session" dialog as usual. This executable normally will be somewhere on the (local) client machine and contains the debug information. Enter the target data in the field "Remote" in the format hostname:portnumber, where portnumber is the number passed as argument to gdbserver on the target. For details please consult the gdbserver man page. To interrupt a running program, press Ctl-C on the remote machine in the console gdbserver is running in. See also the file readme.txt.