ABI Instrumentation project
This project aims at making the compiler emit information (aka instrumentation) about the API and ABI of the translation unit upon compilation. That information can then be used by an offline tool to analyse the API and ABI of a set of translated units that got linked together to produce programs or libraries, or even just header files. That analysis can thus help to answer questions like:
- Is this version of this library compatible with its previous version?
- Is this version of plugin compatible with the program that is going to load it?
Emit XML Output from GCC for prototyping purposes
Currently, G++ has been modified to emit XML output for each translation unit. That output can then be read by libabigail to build an in-memory model of the ABI of the translation unit.
There is a modified GCC in the abi-instr that has a -fdump-abi switch. That switch makes cc1plus emit the instrumentation for a given file foo.cc into a file foo.cc.bi.
To do this, there is a new gcc/cp/abi-instr.cc file that exports new instrumentation routines like abi_instr_emit_function and abi_instr_emit_variable. These routines are then used in cp_write_global_declarations (which is the G++ implementation of the lang_hooks.decls.final_write_globals hook called in compile_file) to emit instrumentation for each function and global variable that is emitted. Then, the emitted instrumentation (that is kept in-memory) is serialized at the end of the compilation. That serialization happens when cxx_finish calls the new abi_instr_finish function. Note that cxx_finish is the G++ implementation of the land_hooks.finish hook that is called at the very end of the compilation process.
Read/Write XML Output using libabigail
Limitations and future work
No support for DWARF
We need to support de-serializing DWARF to build the in-memory model. We also need to extend DWARF to make it support uninstantiated function and class templates.
Nothing emitted for header files
When we support reading ABI information from DWARF, we'll need to devise a way for getting API information for header files. Maybe having new elf files that just contain debug information for header files?
http://sourceware.org/libabigail is still work in progress. There are a lot of constructs that are not yet supported and infrastructure needed to perform a diff of two translation_units and represent the resulting changes.
Getting and compiling the GCC Branch
The current work in the abi-instr GCC Branch can be checked out using Git only, by doing for instance:
git clone --branch dodji/abi-instr git://gcc.gnu.org/git/gcc.git gcc-abi-instr.git
Once you've done that, the code will be in the gcc-abi-instr.git directory of the current directory.
To compile that branch, besides the usual GCC build prerequisites, you will need to get the libabigail source code, compile it, install it under a prefix and give that prefix to the --with-abigail option of the configure script of GCC. That is:
git clone git://sourceware.org/git/libabigail.git cd libabigail.git autoreconf mkdir build cd build ../configure --prefix=</some/abigail/prefix> make all install
And then now configure the abi-instr branch of GCC by doing:
cd gcc-abi-instr.git mkdir build ../configure --with-abigail=</some/abigail/prefix>
Note that you might want to add other options to the configure of GCC to pass it its other prerequisites and whatnot.
And then compile GCC!
Please also note that the abi-instr branch is regularly rebased on top of GCC trunk. So if you intend to hack on the branch in your own cloned repo, please create your own branch that tracks abi-instr and do your hacks there.