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:

Current status

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

Libabigail can read an XML representation of the ABI of the program to build an in-memory model. That in-memory model can be serialized back to XML. Checkout the relevant API.

Diffing support

There is work going on to perform a diff between two translation units and represent the resulting change at Libabigail level. Checkout the abi-diff branch for the code being thrown at that problem.

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?

Complete libabigail

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.

None: ABIInstrumentation (last edited 2013-11-20 10:28:13 by DodjiSeketeli)