The Debugger Interface
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 debugger gdb through a pipe. The debugger can be started in several ways:
With Debug Start, 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:

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, 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.

Breakpoints
(... to be written ...)

Frame Stack
(... to be written ...)

Disassemble
(... to be written ...)

Setting Breakpoints
(... to be written ...)

Options

Display Mangled Names
In C++, function names in the executable are mangled, 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 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
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, KDevelop 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, KDevelop tries to set the pending breakpoints.

Enable Floating Toolbar
(... to be written ...)