8.1.15. Dead Code Analysis¶
8.1.15.1. Background¶
You have a C/C++ project and want to modify the default settings for dead code analysis.
8.1.15.2. What can be configured?¶
Useful things to consider:
Is the code you analyze a library DLL?
Do you have additional entry points, e.g. interrupts?
In addition, if you are using Qt, Qt Creator
describes how you can avoid dead-code messages for methods generated via the
Q_OBJECT macro.
8.1.15.3. What needs to be done?¶
Dead code analysis looks for so-called entry points into the code and starts a reachability analysis on the basis of the call graph information. It covers static calls, dynamic calls, and accounts for virtual function calls. In addition, any function whose address is taken inside an alive function is considered alive.
On a per-project level:
Default entry points are — by convention — the function with names
main,DLLmain,winMain, etc.For DLLs under windows, activate rule
EntryPoints-EntriesByDLLExportto collect all DLL-exported functions as entries, technically speakingSetting parameters for DLLs.¶#define DLLEXPORT __declspec(dllexport) #define LIB_XY_API DLLEXPORT extern LIB_XY_API std::string base_dir();
Define additional entry points with the other rules in rulegroup EntryPoints, e.g. using the linkname (
R DMAHandler()) or via interrupts in code (__attribute__((interrupt))). Sample code:Setting entries via interrupts.¶#ifdef __AXIVION__ #define INTERRUPT __attribute__((interrupt)) #else #define INTERRUPT __interrupt #endif
On a cross-project level:
Things become more complicated and you will have to define a meta project that collects the results from all prior projects and that analyses these results in addition. Note that you may want to suppress all other analyses.
Build all of your projects, collect the various RFG files from the projects.
Use the rule
Architecture-CombinedDeadCodeorArchitecture-VariantDeadCodein order to calculate the dead code using the individual RFG files from the projects collected above.