

Table of Contents
For C and C++, KDevelop 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 ->, the main program of your project is loaded into the debugger.
Using ->-> 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 ->-> 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 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).
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,
i.e. 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 button or pressing Return while the Watch item is selected. They can be removed again via the context menu.
(... to be written ...)
This window allows you to see and manipulate the breakpoints. Remember that KDevelop uses GDB, so to fully understand the KDevelop debugging features, you should know a little bit about the GDB.
If you want to look at the source code, breakpoints are defined in
kdevelop/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.
(... to be written ...)