Enla 1.2With additional contributions by Joseph Heenan.
ENLA 1.2 is a program for going through all the object files
of a C program and reporting on routines which aren't reachable
from main(). It gets its name from the original
method it used for working this out, when it just listed symbols
Exported but Not Linked Against. These days it's a bit cleverer
and actually builds a complete call tree of your program.
UsageWhat Enla does is examine all your object files and build a call graph of all the code areas therein. This is not a great deal of use if all the routines from each source file go into the same code area in the object file, which is the default. Thus, to get Enla to do its job, you have to recompile your object files giving the compiler the option -zo, which makes it put each routine into a separate code area in the same object file.
That works for Acorn (Norcroft) C version 5, anyway: I don't know about C 4 or GCC. It doesn't work with the Windows ARM SDT version of C 4, although it does work with the RISCiX version of C 5.
That done, you just invoke Enla (which should be put in your library directory) with
enla file1 file2 file3...
naming all your object files. As of version 1.2, wildcards are accepted, so for most projects all you need to do is change to your o directory and issue "enla *". Enla will output a complete call graph of your program (pruned so each routine only appears once) and also tell you which routines aren't called anywhere, and which routines are called only from within the same source file (and thus could be declared static, offering the compiler a chance to perform further optimisations).
You can then go through your source code ifdef'ing out or deleting anything you no longer need. The bigger your program, and the more people who've worked on it over the years, the more you stand to gain.
Points to noteAs of version 1.2, you can use wildcards on the command line. The code to implement this was kindly contributed by Joseph Heenan.
You probably don't want to use the -zo option for production code, as it makes your object and binary files several percent bigger.
Enla doesn't cope well with the situation of two routines, each declared static to a different source file, but having the same name. One or other will probably be wrongly described as not called.
Enla can't diagnose when a function assigned to a function variable is never called. This includes things like the "method" functions for the anim library in InterGif, where a structure full of function variables is used to simulate C++'s "virtual functions" facility.
Enla doesn't follow links into libraries, and won't cope with library files on its command line. This is partly because it's a fair bit more work (an almost complete reimplementation of the linker) and partly to preserve world peace, as I'm sure the masses would descend on Acorn House with pitchforks and blazing torches if they ever found out quite how much cack gets linked into their programs if they use RiscOS_Lib, a staggeringly bad piece of library design.
Don't bother porting Enla to Windows. Microsoft Visual C++ has a function-level linker anyway, and routines unreachable from main() just don't make it into your binaries. (Essentially, VC++ always has its equivalent of -zo set. I don't know whether this means its code is always a few percent worse than it could be; that may be due to a property of ARM code which x86 code doesn't exhibit.)
DistributionEnla is NOT COPYRIGHTED and is NOT distributed under the GNU General Public Licence.
Downloading Enla 1.2: Just click here (9K).
Downloading the source to Enla 1.2: Just click here (14K). It's up to you what you do with the source -- but if what you do with it is make bug-fixes or improvements to Enla, I'd like to request that you send them to me so that this page can always offer the "best" version.
Incidentally, I've made that request for all the bits of software on this Web site for years now -- and (except for some now-defunct code a coworker contributed to InterGif) Joseph Heenan's contributions to Enla constitute the first time anyone has taken me up on it. Thanks, Joseph!