The Debugger Settings Dialog

This is accessed by Settings > Debugger Settings




The first page of the dialog contains an entry for each known debugger. (As the only known debugger is likely to be gdb...). The first field is the Path to the debugger, and will usually be blank. However, if your installed gdb can't be found, or if you have more than one version available, you can specify the filepath here.

The next field is a collection of breakpoint options:

  • Enable pending breakpoint - this is self-explanatory; it may or may not work, depending on your platform and gdb version
  • Automatically set breakpoint at main - this can be useful if gdb can't find your breakpoints' source files until the app is running. Breaking at main() gives you the opportunity to set them before your app crashes ;)
  • Break when C++ exception is thrown - makes gdb break when an exception is thrown. NB. this will fail for some versions of gdb, on some platforms. If so, set a breakpoint on main, then do 'catch throw'.
  • Break at assertion failure (MinGW only) - This is necessary on MinGW; without it, the application being debugged will crash if it asserts, preventing you from debugging the cause.

Next is a group of miscellaneous options:

  • Enable full debugger logging - if checked, CodeLite will emit a large number of messages in the Debug tab. This is mostly useful if you're trying to debug CodeLite's debugging.
  • Show debugger terminal - when debugging starts, a terminal window appears; program output may appear there. Unchecking this box theoretically prevents the window appearing; in practice, it still does anyway :(
  • Use file name only for breakpoints (NO full paths) - useful for remote debugging.
  • While debugging, show debugger tooltips - the output from hovering over a variable now appears in the the Ascii Viewer. In previous CodeLite versions it used to appear as a tooltip. If you check this box, the output appears in both places.

Last is two items related to how things are displayed:

  • Limit how many elements GDB will print - for very large arrays, the resulting display wouldn't fit on the screen. This allows you to keep the size sane.
  • Evaluate items in the 'Locals' view... - if checked, CodeLite will display the value of e.g. wxStrings in the 'Locals' view. However this needs quite a long conversation with the debugger; if you have dozens of wxStrings in the function being debugged, that can take a long time. If it's a problem, switch off the behaviour here (you can still display the value by double-clicking on the item and opening up the resulting tree until the text appears).


The second page is Pre-defined Types. This is where CodeLite lists its artificial intelligence: the way it knows how to display in a human readable way the contents of e.g. a wxString (even in a unicode build) or a std::vector.





The 'New Type' dialog


You can add your own entries by clicking the New button. For example, I'm writing this when the most recent wx release is 2.9 with the new-style wxString, on which CodeLite's current method fails. To add a way that works, fill in the dialog as shown.



You should now be able to see the contents of a 2.9 wxString by choosing 'Watch as wxString29' from the editor contextmenu.

Note the use of the macro $(Variable) here. This is the only macro that can be used in this situation. The macro expansion is also case sensitive.