Static analysis tool to detect ABI breaks in C++

Question

It's not very hard to break binary backwards-compatibility of a DSO/shared library with a C++ interface. That said, is there a static analysis tool, which can help detecting such ABI breaks, if it's given two different sets of header files: those of an earlier state of the DSO and those of the current state (and maybe DSOs as well)? Both free and commercial product suggestions are welcome.

If it could also warn about bad practices, e.g. inline functions and defaulted function parameters in DSO interfaces, it would be great.

Answer 1

I assume that you are familiar with this tutorial: Binary Compatibility Issues with C++, if not read it!

I've heard about this tool: http://ispras.linuxbase.org/index.php/ABI_compliance_checker, however never tested or used one, so have no opinion.

Also this may interest you: Creating Library with backward compatible ABI that uses Boost

Answer 2

abi-compliance-checker - a tool for checking backward binary/source-level compatibility of a shared C/C++ library (DSO):

A tool for checking backward binary and source-level compatibility of a C/C++ library. The tool checks header files and shared libraries of old and new versions and analyzes changes in API and ABI (ABI=API+compiler ABI) that may break binary and/or source compatibility: changes in calling stack, v-table changes, removed symbols, renamed fields, etc.

icheck - C interface ABI/API checker:

A tool for statically checking C interfaces for API and ABI changes. All changes to type declarations that can cause ABI changes should be detected, along with most API changes. icheck is intended for use with libraries, as a method of preventing ABI drift.

shlib-compat - ABI compatibility checker for shared libraries with symbol versioning:

shlib-compat uses dwarf debugging symbols to recreate and compare definitions of exported symbols, including function arguments and structural types.

Also you might be interested in the linux upstream tracker and linux abi tracker services. They are both powered by the abi-compliance-checker tool.

Answer 3

I remember at work they used GCC XML for testing binary compatibility. Basically what it does is generate an xml representation of the compiler object tree. The theory goes that if the xml is equivalent, they binary compatibility has been maintained.

Answer 4

The only safe way to do this is to export your library using a C interface. A C++ library is only compatible with the one compiler you use to compile it.

Answer 5

Our C++ Smart Differencer tool compares two source files and reports differences in terms of language structures (identifiers, expressions, statements,...) and plausible editing actions (insert, delete, move, copy, replace-identifier, ...).

It doesn't answer the ABI question directly, but the information it provides might be pretty helpful. An example discussed in another answer is change-of-return-type from struct {a,b} to struct {b,a}. SmartDifferencer would report that a was moved. (Note: a regular diff tool would report the that line containing the struct definition was changed, so you kind of get the same information, but SmartDifference will ignore changes in whitespaces/layout and comments, too, producing less conceptual noise).

What neither of these tools will report is the change of the definition of a typedef, it is in another header file. But then presumably one would compare all header files involved. If you don't want to do this manually, whatever tool is in use must included essentially a full C++ parser, name resolver, and must compare the declarations for equivalence. Another poster suggested pretty much that answer: comparing GCCXML output for equivalence. I'm not sure how easy that is in practice; it can't be just "are the files the same XML in order?".

Answer 6

ABI - Application Binary Interface comes down to the way the compiler translates the source code into the machine recognizable instructions. the same source line can be translated to different stream of bytes, in the final program.

a static analyzer running over the source code will not be able to predict how the compiler will translate it. that decision is made in the compiler coding or settings. so I don't believe a static analyzer will be of help to you in this case.