Next Previous Table of Contents

### 13. The Internal Debugger

### 13.1 Setup

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:

- Display static members: Displaying static members makes gdb slower in producing data within kde and qt. It may change the "signature" of the data which QString and friends rely on. But if you need to debug into these values then check this option.
- Display mangled names: When displaying the disassembled code you can select to see the methods mangled names. However, non-mangled names are easier to read.
- Try setting BPs on lib load: This will try to set pending breakpoints on loading a library. If GDB hasn't seen a library that will be loaded via "dlopen" then it will refuse to set a breakpoint in that code. We can get gdb to stop on a library load and hence try to set the pending breakpoints. See Shared libraries and breakpoints for more details and a "gotcha" relating to this behaviour. If you are not "dlopen"ing libs, leave this off.
- Enable floating toolbar: This will allow you to use the floating toolbar to control the debugger in addition to the menu and buttons. The toolbar is most useful for debugging GUI applications. For details see The floating toolbar.
- Enable separate terminal for application i/o: This allows you to enter terminal input when your application contains terminal input code (eg cin, fgets etc.). If you use terminal input in your app, then tick this option. Otherwise leave this off. Tip: This option is most useful, if you use it in combination with the floating toolbar, because this way, the terminal window won't be hidden behind the KDevelop window when you control the debugger.

### 13.2 Using the internal debugger

#### Changes made in the tree and output view window

If you choose the internal debugger, four tabs are added to your tree and output view windows.

#### On the tree view window

- VAR tab : A tree view of the local variables at the current place in the program you have stopped at. You can also see local variables in the function that called this functions. The VAR tab also contains a watch window. This allows you to see the value of global variables, or perhaps you may want to see only one local variable rather than the variable in a large list of local variables.

#### On the output view window

- breakpoint : A list of breakpoints set and their current state.
- framestack : The calling stack.
- disassemble : A machine instruction view of the code showing the current instruction to be executed.

#### Changes made in the Debug menu and on the panel

#### On the panel

Two normal and two dropdown buttons to control the debugger functions will be accessible as soon as you start the debugger.

#### In the Debug menu

When you start debugging, ten items to control the debugger will be enabled.

Available functions:

- Run: Continue the program from the current point.
- Run to cursor: Execute the program up to the current cursor position
- Step over: Execute one line of code stopping on the next line of code in the same surce file. This will run any functions encountered until the above condition is met.
- Step over i(nstruction): Execute one machine instruction as above.
- Step in: Execute exactly one source line of code. This means you will "step into" the current function, if necessary
- Step in i(nstruction): Execute one machine instruction as above.
- Step out: Run to the end of the current stack frame (function)
- Viewers: Allows a variety of views into the data. Currently implemented views are:
  1. Memory address
  2. Disassemble code
  3. Current registers
  4. Current libraries
- Interrupt: Stop the application executing.
- Stop: Stop the application executing and exit the debugger.

#### Details

#### Breakpoints

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.

#### Set/Unset breakpoints

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.

#### Alternative beakpoint manipulating via menus

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.

#### Editing breakpoints

Use the above menu to display the edit breakpoint dialog. This contains the following fields :

1. Conditional: Enter the condition that must be met before gdb will interrupt the program execution.
2. Ignore count: How many times you want the code to past through this breakpoint before gdb interrupts the program execution.
3. Enable: When enabled gdb will break at this breakpoint. When disabled gdb will not break here.

#### Clear all breakpoints

Removes all the breakpoints for this program.

#### Set/Unset watchpoints

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"

#### Set/Unset Watch variables

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.

#### Changing variable values

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.

### 13.3 The floating toolbar

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:

- Set focus on kdevelop : Set the focus on kdevelop
- Set focus on app : This sets the focus on the window that had focus when you pressed the "set focus on kdevelop" button. This is a compromise, it should set the focus on the application being debugged but this is difficult to do. If anyone has a better solution than the current functionality then please let us know.

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.

### 13.4 Shared libraries and breakpoints

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