The Debugger Interface debugger For C and C++, &tdevelop; contains an internal debugger that is directly integrated with the editor. Technically, it is implemented as a frontend that uses the portable &GNU; debugger gdb through a pipe. The debugger can be started in several ways: With DebugStart, the main program of your project is loaded into the debugger. Using Debug Start (other) Examine core file you load a core file into memory, which is generated by the operating system kernel when the program has crashed (The generation of core files may be switched off on your system, see ulimit(1)). This is useful for a post-mortem analysis of a program. With Debug Start (other) Attach to process you invoke the debugger on an already running program. You will be shown a process list where you can select the process which the debugger should take over. Note that debugging is only possible if your project has been compiled with debugging information enabled. It can be activated in the Compiler options dialog. When this option is switched on, the compiler generates additional data which allows the debugger to associate file names and line numbers with addresses in the executable. The debugger frontend offers several views into the process: If you try to debug a project without debugging information, you get the message No source... in the status bar.If you try to set a breakpoint, it is shown as Pending (add) in the breakpoint window (see below). Variables watch variables This window lists the values of all local variables at the current execution point of the program. It covers the variables in the complete call stack, &ie; the function where the process was interrupted, the function that called this function, and so on up to main() function. Another branch in the variables contains watch variables. You can configure yourself which variables are shown here. Both local and global variables can be watched. You can add variables either by clicking on the Add button or pressing Return while the Watch item is selected. They can be removed again via the context menu. Frame Stack frame stack (... to be written ...) Breakpoints breakpoints This window allows you to see and manipulate the breakpoints. Remember that &tdevelop; uses GDB, so to fully understand the &tdevelop; debugging features, you should know a little bit about the GDB. If you want to look at the source code, breakpoints are defined in tdevelop/languages/cpp/debugger/breakpoint.h. At the left edge, the window has buttons to: Add an empty breakpoint Edit the selected breakpoint Delete the selected breakpoint Remove all breakpoints The main part of the window is a table with 7 columns. Each line in the table is a breakpoint. The columns are: Selection checkbox Type: one of: Invalid, File:Line, Watchpoint, Address, Function Status. Values are: Active Disabled: Each breakpoint may be enabled or disabled; if disabled, it has no effect on your program until you enable it again. Pending (add): a breakpoint is marked like this if no debugging information is available. From GDB Info page:
If a specified breakpoint location cannot be found, it may be due to the fact that the location is in a shared library that is yet to be loaded. In such a case, you may want GDB to create a special breakpoint (known as a pending breakpoint) that attempts to resolve itself in the future when an appropriate shared library gets loaded.
Pending (clear) Pending (modify) Location in the format filename:linenumber Condition Ignore Count: If this is a number COUNT greater than zero, the next COUNT times the breakpoint is reached, your program's execution does not stop; other than to decrement the ignore count, gdb takes no action. Hits: counts how many times a breakopint has been hit. Disassemble disassemble (... to be written ...) Setting Breakpoints (... to be written ...) Options Display Mangled Names name mangling manglingname In C++, function names in the executable are mangled, &ie; the function names include information about the argument types. This is necessary in order to support overloading of functions. The mangling algorithm is not standardized and differs even between different versions of the &GNU; C++ compiler. In the disassembling window, normally unmangled names are displayed, so function signatures appear in the similar way as in the source code, so they are easily readable. Alternatively, you can decide to see mangled names. Try Setting Breakpoints on Lib Load lazy breakpoints breakpointslazy The debugger backend gdb does not allow to set breakpoints within code that is not currently loaded. In a highly modular application, where often code is only loaded on demand as a plugin (using the libc function dlopen(3)), this can be inconvenient. Therefore, &tdevelop; rolls its own support for breakpoints in shared libraries. If you set this option, it allows you to set breakpoints in libraries which are not loaded. Then, whenever gdb notifies that a library is loaded, &tdevelop; tries to set the pending breakpoints. Enable Floating Toolbar debugger toolbar toolbardebugger (... to be written ...)