callcatcher: collect functions/methods defined and subtract called/referenced ============================================================================= For each file processed compile to assembly and detect all the functions defined, seperate them into virtual and nonvirtual. Then detect all the functions called or obvious instances of taking functions addresses. All output data is stored in ~/.callcatcher and is persistant between runs to achieve a global analysis of a project. To install > ./setup.py install To analyse, when all files of the project have been compiled, run > callanalyse ./finaloutput and we subtract the called functions from the list of nonvirtual defined functions. (By extending this and using gcc with -fvtable-gc, we would also probably be able to detect what hierarchies of virtual methods could not possibly have been called and include those as well, but for the moment we just ignore virtual methods) e.g. callcatcher g++ -c test.cxx -o test.o callcatcher g++ -o mytest test.o callanalyse mytest typically for autoconf and cmake etc, setting CC/CXX/AR is sufficient export CC="callcatcher gcc" export CXX="callcatcher g++" export AR="callarchive ar" ./configure && make The tool attempts to know what the dependant components are for a given output file, and so in the example above ./analyse.py mytest will only report on the combination of object files known to comprise mytest Unused, but well-formed methods are not reported, e.g. unused copy constructors and unused assignment operators unless --strict is used. For LibreOffice use the built-in target in the toplevel LibreOffice makefile of make findunusedcode Examples -------- An individual module > make... > callanalyse lib/libsw580li.so A collection of binaries > callanalyse */lib/*.so */bin/* callcatcher can understand map files, e.g. > callanalyse --mapfile util/sal.map lib/libuno_sal.so.3 use callarchive to intercept calls to "ar", e.g. > callarchive libtest.a test.o Cons: ----- * Fragile use of assembler output * It deliberately detects and discards virtual methods, so doesn't report any virtual methods which might be unused Pro: ---- * No false positives * Works on ix86 and x86_64 To do: ------ * Now that gcc supports user-written plugins converting this to a gcc plugin might make more sense than scraping assembly Caolán McNamara (2008-2012) <caolanm@redhat.com>