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 ~/.callcollector and is persistant between
runs to achieve a global analysis of a project.
> ./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)
callcatcher g++ -c test.cxx -o test.o
callcatcher g++ -o mytest test.o
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
Ununsed, 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
Examples An individual module
> 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
Fragile use of assembler output
It deliberately detects and discards virtual methods, so doesn't report any virtual methods which might be unused
No false positives
Works on ix86 and x86_64
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) <firstname.lastname@example.org>