Using Breakpoints

---

During a debugging session, CodeLite can set breakpoints, temporary breakpoints and watchpoints. These can be conditional, ignored or disabled, and can be associated with command-lists. Breakpoints can be set by file/line-number, function or memory address.

---

Setting Breakpoints

Setting Breakpoints by line-number

This is the commonest type of breakpoint, and there are three ways to set one. The easiest is to click on the left margin of that line, just to the right of the line-number. This creates a new breakpoint on that line. Clicking on a line which already has a breakpoint deletes the breakpoint (were there multiple breakpoints on the line, a dialog would appear where you can choose which to delete). Exactly the same could be done by using the Debug > Toggle Breakpoint menuitem, or the associated shortcut, F9 by default.

Another way is via the margin's context menu. As well as adding a normal breakpoint, this also lets you add a temporary or a conditional one. If, as shown, the right-click was over an existing breakpoint, there are also options to remove, ignore, edit and (if the debugger is running) disable that breakpoint; again, with multiple breakpoints you get a 'Which one?' dialog.

The third way to add a line-number breakpoint is from the Breakpoints tab of the Debugger pane, as described below.

A breakpoint on a line is indicated by an icon in the margin. There are icons for each type of breakpoint:

A breakpoint icon's tooltip displays information about the breakpoint e.g. its condition or commands.

Setting other types of Breakpoint

Setting a breakpoint on a function or at a memory address can only be done from the 'Create a breakpoint...' dialog. To run this dialog, click the 'Add' button in the Breakpoints tab of the Debugger Pane.

This dialog lets you add a breakpoint by line-number/file as above, or by function e.g. MyClass::Foo or memory e.g. 0x12345678. At the same time you can add any condition e.g. n<2, and/or commands to run when the breakpoint is hit. You can also make the breakpoint be temporary, or set its ignore level. However, for technical reasons, you can't create a disabled breakpoint here; instead create it enabled, and then disable it.

This dialog has informative tooltips, to help you set more complex breakpoints correctly.

Setting Multiple Breakpoints

If you need to set more than one breakpoint at a location (Why? Well, one might have one condition, another a different one, each with a different command-list...), you can do this using the second and third methods above. When editing at that location, a dialog will appear that lets you choose which you want to edit.

---

Editing Breakpoints

If you right-click over a breakpoint symbol, the resulting context menu allows you to set the 'ignore' level of the breakpoint; and, if the debugger is running, you can also disable/enable it.

You can also edit a breakpoint using a version of the 'Create a breakpoint...' dialog. To obtain this, choose 'Edit' from the breakpoint's context menu, or right-click the breakpoint's entry in the Breakpoints tab of the Debugger Pane, or select it in that tab and click 'Edit'. The dialog is identical to the 'Create' one, except that (if the debugger is running) there's an extra option of disabling/enabling the breakpoint.

---

Miscellaneous

Generally you can create and edit a breakpoint even before the debugger starts. Similarly, existing breakpoints will remembered by CodeLite when the debugging session finishes; indeed they are serialised. However, for technical reasons, it isn't possible to create a disabled breakpoint, or for it to persist once the debugging session ends. It will be deserialised enabled. (Of course you can always disable it again once the debugger restarts.)

If you have a breakpoint, and you need it on a different line, you can move it there by drag-and-drop, using Shift+Left-button. That's not particularly exciting if it's just a standard breakpoint (it would have been at least as easy to delete it and create a new one); but if the breakpoint has complicated commands or conditions, it saves you having to enter these again. For the technical reason just mentioned, a disabled breakpoint will be enabled in its new location.

You may wish to set breakpoints inside a shared library that will be loaded by your program. In theory, you can warn gdb that you're doing this by checking the Enable pending breakpoints box in the Debugger Settings dialog; in practice this doesn't always work. So CodeLite stores any breakpoints that gdb can't apply; when this happens, an extra button appears in the Breakpoints tab of the Debugger Pane, Set Pending. Clicking this tells gdb to try again; if it succeeds, the button will disappear again and the breakpoint entries and markers will become visible.

---

Watchpoints

A watchpoint is similar to a breakpoint but, instead of breaking when that code is hit, it breaks when a variable (or an area of memory) is changed or accessed (see http://www.delorie.com/gnu/docs/gdb/gdb_30.html for more information).

You can only set a watchpoint from the 'Create a breakpoint...' dialog as described above. Use the wxChoice at the top of the dialog to create a watchpoint instead. Again the tooltips should be helpful.

Note that the most common situation for wanting to use a watchpoint is to watch for alterations to a variable. However, as soon as that variable loses scope, gdb deletes the watchpoint. This makes it difficult to watch a local variable.