Libabigail is shorthand for the alternative, which just so happens to be a bit of a mouthful: “GNU Application Binary Interface Generic Analysis and Instrumentation Library.”
This is a current compiler/language research topic to provide a serialized XML form of C++11 sources as compiled by GNU g++, and a way of looking at the data produced. This data can be parsed to more accurately determine ABI compatibility, to better understand code additions and changes and how these change the exported interface, to examine and prototype how C++11 language usage determines linkage, etc.
Discussions about this functionality started at the “C++ ABI BOF” at the GNU Tools Cauldron 2012 Prague. This work was created at Red Hat, by Benjamin Kosnik, Jason Merrill, and Dodji Seketeli. Some updates at 2013 Cauldron. See “Cauldron 2013 GCC ABI BOF.”
Development sources are written in mixed C++2003/C++11, hosted in git, based on GCC trunk, and tracking what will to be gcc-4.9.0. The branch is administered by Dodji Seketeli.
Please feel free to try it out, but know that the state is experimental and quite raw.
Feedback and assistance is welcome.
Starting from a git working tree as described in GitMirror, add the
libabigail repository as follows:
git checkout -b libabigail origin/libabigail
To stay up to date, use:
How is this expected to be used? First, a libabigail top-level directory is either added to the GCC sources or compiled as a first step and put into some PREFIX directory. The GNU C++ compiler, g++, is configured to use this new library with:
configure .. --with-abigail=$PREFIX
Thus configured, the C++ front end is built, installed, and used as the primary compiler. All sources are compiled with an additional flag, -fdump-abi.
So, this command:
g++ -c -fdump-abi somefile.cc
Creates two files:
Toplevel namespace is abigail.
The interface header files in libabigail:
Doxgen is used to document the sources: try
make html to generate, and look in
libabigail-build-dir/doc/api/html/index.html to read it.
And then the binary interface is in
Each object file is compiled to a translation_unit. The sum of all translation_units is a corpus.
Compiler-generated files are read as serialized input to a
translation_unit and de-serialized. And any modified form is written to an output file in serialized form.
The interface to the C++ intermediate representation is best viewed in the class documentation.
Opinions and Wild Guesses
1. Some formatting tips.
- classes “read” as types, data, members functions. In that order.
- doxygen gives feedback on the state of the doxygen parse in the form of a log, as you run “make html.” Read this log: doxygen is a fuzzy parse. There are formatting things you can do to make it better. Do them. It’s easier to fix up these errors then figure out why the generated HTML is poor.
2. Use of shared_ptr is intriguing.
There are not really a lot of existing usage patterns for
libstdc++ (in C++11
). If you look at the page of boost idioms for
One notices that there’s not a lot of use of shared_ptrs in interfaces. Yet in libabigail, that is very common. I’m curious about this style question.
And most usage is up for debate, see this stack overthow discussion about using shared_ptrs as function arguments. Should the parameters be const reference or just shared_ptr? And another.
Some interesting thinking from microsoft on shared_ptr usage.
3. Use of virtual binary operators is odd.
The old adage is that operators cause havoc in overload resolution. These are binary operators, but the stigma lingers. A vague feeling is not the same as something definite that’s a hard no. It’s more like the pirate code than a strict coding convention or hard rule. I would say that if you ever start to see strange bugs due to overloading, consider making these (non-operator) functions.
Otherwise, do it.