Using a debugger along with Intel® Inspector XE 2013 can be a powerful combination, giving access to information about variables and workflow at the time of an issue that are not directly accessible through the use of one tool alone.
You may wonder why you would want to do this, because you could simply attach a debugger to a running analysis. The difficulty is that Intel® Inspector XE does binary runtime analysis of your application, which means that if you attached a debugger to it, you would be looking at that analysis tool’s code much of the time and learn nothing about the problem the tool was reporting in your code.
Likewise, you could use Intel® Inspector XE to get the location of an issue and just set a breakpoint there and run the debugger to it. However, the code in question might be executed correctly dozens or hundreds of times, depending on your code, before the time that it actually triggers a correctness or threading error.
The most effective way to find the exact location you want is to use the integrated debugger functionality. There are three different ways to launch analysis with the debugger, depending on your exact situation.
Memory and resource leaks are not amenable to analysis with the debugger, because these leaks are not discovered until after the analysis run has ended, so there is no opportunity to break on them. For this reason, running with the debugger is not available with the lowest, leak only, version of memory checking and the “debug this” context item is not available for resource or memory leak problems.
Debug This Problem
If you have already run analysis, you may wish to break into the debugger only on one or more of the found problems.
Debug This Problem – Windows* and Linux* GUI
Click on any non-leak problem and bring up a context menu. Select “Debug This Problem” and the tool will immediately re-run analysis and break into the debugger when this specific issue is found.
Debug This Problem – Linux* CLI
Command line support for the Debug This Problem will rerun an analysis with debug enabled. Analysis configuration for the specified result is re-used as-is. This feature uses new options:
-reinspect ,-breakpoints <ProblemID>,<ProblemID>,... -breakpoint-list <filename>
When a -breakpoints or -breakpoint-list option is given, the CLI will automatically run until it hits one of those breakpoints
Enable Debugger when problem detected
Using the Windows* or Linux* GUI, when launching a new analysis at any level other than Detect leaks, the user now has the option to select breaking into the debugger as soon as any problem is detected. Running both the analysis tool and the debugger has a negative effect on performance, so this should be used only when more detailed information is required and not as a default running condition.
Delay analysis until breakpoint
The user now has the ability to run the application without analysis until you reach a breakpoint and then start Intel® Inspector XE analysis at that point. This can, when used carefully, really speed up run time.
Delay analysis – Windows* and Linux* GUI
Before you begin your run, go into the source code and specify the breakpoint(s) that you would like to stop on. Then when you start the Intel® Inspector XE tool, select the button for “Select analysis start location with debugger”.
Delay Analysis –Windows* and Linux* CLI
The CLI has a new option: -appdebug <off | delay-analysis | on-error | on-start>
The “delay-analysis” choice causes a debug analysis session to begin with analysis turned off. The session will stop on entry to main() and allow the user to set a code breakpoint at a location they choose and run to it before turning on analysis using the begin-analysis command.
Starting analysis after breakpoint
When the user selects startup with delayed analysis (through GUI configuration option “Select analysis start location with debugger” or CLI option -appdebug=delay-analysis), there is a command to turn on Intel® Inspector XE analysis after the user has executed to the point of interest.
On Windows*, a single Debug menu item Continue with Inspector XE Analysis combines enabling analysis with resuming execution.
On Linux*, an interactive command is used to enable analysis and the user must issue a continue or step command separately.
For CLI use interactive command: monitor begin-analysis.
Interaction with the debugger within the GUI
When the tool breaks into the debugger, all the standard debugger options are available. You can see the value of variables and step into and out of functions just as normal.
If you are using one of the GUI clients, in the lower right corner of the screen you will see information about the problem you have broken on and options:
Clicking on the Intel Inspector button will release you from the debugger and return you to an actively running Inspector XE session. Clicking on Disable Breakpoint will allow you to not break on this problem if it is encountered again in the run. Clicking on Re-enable Breakpoints will take you to a list of breakpoints you have previously disabled, in case you wish to return them to service, and Explain will take you to appropriate Inspector XE help documentation.
Choice of Debuggers – Linux* only
The user can select which supported debugger, GNU gdb* debugger or Intel® Debugger, to launch.
Linux* CLI - use environment variable INSPXE_DEBUGGER=<gdb|idb|idbc|none|executable pathname> or CL global option: -debug-using=<gdb|idb|idbc|none|executable pathname>
For the standalone Linux*GUI - in the File->Options dialog, there is a new category for Debugger with debugger choices listed. Default selection is GNU gdb*.
Having the error finding power of Intel® Inspector XE 2013 and the fine grained source information available from a debugger at your fingertips makes it much simpler to solve truly complex issues especially in code with complex control flows. The integrated debugger functionality will allow you to focus in on just the issues that matter to you and just the passes where those issues occur.