CodeLite IDE | Main / DebuggingWithQuickDebug

Sometimes you'll want to use CodeLite just as a front-end to gdb: in other words, to launch and debug a binary that doesn't have a CodeLite workspace. You can do this with 'Debug -> Quick Debug'. This brings up the Quick Debug dialog, which has boxes for the filepath of the binary to be debugged (essential) and the Working Directory to which to change (less essential); and one for any arguments to pass to the program (not essential). You can also select which debugger to use (the likely choices being gdb or none :p) and "Startup Commands", where you can add commands to be passed direct to gdb.

Attach:QuickDebugDialog.jpg

An example is worth a thousand pictures, so let's attack that well-known collection of bugs, the wxWidgets 'minimal' sample ;) Start CodeLite, and open the Quick Debug dialog. Fill in the first two boxes appropriately, then click the 'Debug' button to close the dialog. The debugger will start, and then pause; and minimal.cpp will have opened in the editor. At this stage you can add breakpoints at the lines of your choice by single-clicking in the margin, just to the right of the line-number.

Attach:EditorDebugging.jpg

Now click the Run/Continue button in the Debugger toolbar, or press F5. The program will run, and can be debugged in the usual ways.

What was that entry doing in the 'Startup Commands' box? Suppose you have wxWidgets-2.4.2 installed in your PATH (don't we all); but you feel the urge to upgrade, so you make a local build of wxWidgets-2.6.0. If you compile your app against 2.6.0 and try to debug it, there's a good chance that the debugger will choose to use the wrong set of symbols, and display to you the wrong wx source files. You can stop this happening by passing a command to the debugger via the "Startup Commands" box. In this case the command would be: dir /path/to/wx-2.6.0.