Next Previous Table of Contents
The default setup for KDevelop is to use the internal debugger. You can change this under Options select the "KDevelop setup" menu item, and then the Debugger tab.
Click on "Use external debugger" if you wish to use a different debugger and enter the name of the debugger to use. See your debuggers documentation on how to run it.
Selecting the internal debugger enables an additional set of options you can choose from:
If you choose the internal debugger, four tabs are added to your tree and output view windows.
Two normal and two dropdown buttons to control the debugger functions will be accessible as soon as you start the debugger.
When you start debugging, ten items to control the debugger will be enabled.
Breakpoints can be set against source lines in a file (referred to as breakpoints) or on variables in the source (referred to as watchpoints). Both types of breakpoints can be set at anytime, however watchpoints on local variables only have meaning in the variables local scope. Watchpoints have more meaning when you are dealing with global variables.
Simple one click set/unset. Click on the "icon" border to the left of the text in the editor at the line you want the breakpoint. Click again on this line to unset the breakpoint.
By right clicking on a breakpoint in the breakpoint list or on a breakpoint in the editors icon border you will get a menu of breakpoint options. This allows you to remove this breakpoint, clear all breakpoints, or edit the breakpoint.
Use the above menu to display the edit breakpoint dialog. This contains the following fields :
Removes all the breakpoints for this program.
In the VAR view click with the Right Mouse button on a variable. A popup menu will be displayed allowing you to set a watchpoint on the local variable. This functionality is limited to the scope that the local variable is in. As the variable goes out of scope the program breaks and the watchpoint is deleted.
WARNING: This is known to be problematic, so use caution when setting watchpoints on local variables.
The watchpoint can also be set by a right mouse click on a previously entered watch variable, and selecting "toggle watchpoint"
At the bottom of the VAR view there is the "Watch" field where you can enter the variable name you wish to see display in the watch list. Enter the variable name and type "enter" or click on the "Add" button alongside the field. Right Mouse clicking on the watch variable in the treeview will bring up a menu so that you can remove the variable from the list.
You can also enter a watch variable by right mouse clicking on a variable name in the editor window. This displays a popup menu with "watch: variable name" on it.
This is done via the watch variable. If you have a variable "test" then to set "test" to 5 type "test=5" in the watch field and add it to the list. Note that "test" will be set to "5" EVERY time the program stops at a breakpoint, so once you have set the variable, usually you should remove the item from the watch view.
The floating toolbar is a feature of the internal debugger, which greatly improves your comfort in debugging GUI applications. The toolbar is either on top of all windows displayed, or docked into the panel. When docked you can run your code by clicking on the docked icon. The function this performs is the "step over" function. Right clicking on the docked item allows you to restore the toolbar and optionally place focus on kdevelop.
Besides the functions available from the Debug Menu, the floating toolbar offers two additional functions:
When gdb interrupts the program, probably because a breakpoint has been triggered, we highlight the "Set focus on kdevelop". We do not automatically switch focus to kdevelop so that you can view the application window at this point. Click on the "set focus" button to switch to kdevelop or press a button on the toolbar to perform your selected function.
Shared libraries and breakpoints have a problem that has a reasonable solution. The problem is that gdb will not accept breakpoints in source that is in a shared library which has not yet been opened but will be opened via a dlopen.
The solution is to get gdb to tell us when a shared library has been opened. We do so by setting "stop-on 1". This means that when the user sets a breakpoint, we flag this breakpoint as pending, try to set the breakpoint and if gdb says it succeeded then flag it as active. If gdb is not successful then we leave the breakpoint as pending. The next instruction will always be "continue" .
This is known as "lazy breakpoints"
However, this can lead to a problem when you use the "step over" command and step over code that will load a library. This will trigger a break on the library load, and, normally the debugger would do a "continue" (ie run to the next breakpoint or the end of the code). The user, however, is expecting the program to stop at the next line, so in this situation we do not continue, but leave it at that point (which will be somewhere inside a dlopen command). This is disconcerting but cannot be helped.
Next Previous Table of Contents