The Debugger Settings Dialog
This is accessed by Settings > Debugger Settings
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. Note that this is a global setting and it will affect all the projects. If you wish to change a debugger per-project, you can do so from the 'Project Settings' dialog, under the 'Debugger' page.
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 ;)
- Apply breakpoints after main function is hit - this option tells the debugger to set a temporary break point at main and once this breakpoint is reached, it should set the user breakpoints. This is useful when setting breakpoints inside a shared libraries / DLLs
- 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.
- 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.
User can define number of pre-defined sets and choose which set to use per-project (from the project settings dialog -> Debugger page).
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.
