26

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.

einpoklum
  • 118,144
  • 57
  • 340
  • 684
okun
  • 338
  • 3
  • 10
  • 2
    What makes you think inline function and defaulted parameters are bad practice? –  Dec 28 '09 at 15:15
  • Also, I'm not sure that you understand what ABI means - I can't see what it has to do with header files. Ideally, if you do get an ABI incompatibility, it will be spotted by the linker. –  Dec 28 '09 at 15:16
  • 2
    Maybe it was not so clear that I'm building a DSO. If the library interface has an inline function, it is compiled into the client of the DSO. Thus changing the inline function would not affect the functionality of the application. Same goes for defaulted function parameters. – okun Dec 28 '09 at 15:29
  • DSO? Maybe that's why what you are doing isn't clear. Platform? – jmucchiello Dec 28 '09 at 15:46
  • 1
    Dynamic Shared Object (DSO) aka a shared library. The platforms are Linux and commercial unices. – okun Dec 28 '09 at 15:53

6 Answers6

21

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.

enter image description here

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.

linuxbuild
  • 15,843
  • 6
  • 60
  • 87
15

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

Community
  • 1
  • 1
Artyom
  • 31,019
  • 21
  • 127
  • 215
  • 1
    Yes, I'm aware of the dos and don'ts, which was also my motivation to ask if there was any tool to automate the obvious checks. ABI compliance checker does look helpful. I will give it a try. Cheers! – okun Dec 29 '09 at 13:51
1

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.

doron
  • 27,972
  • 12
  • 65
  • 103
0

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.

jmucchiello
  • 18,754
  • 7
  • 41
  • 61
  • The clients are well aware of the compiler requirements. The DSO is an indoor project and has a wide range of clients throughout the company, but obtaining the very same compiler version is no problem. – okun Dec 28 '09 at 15:57
0

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?".

Ira Baxter
  • 93,541
  • 22
  • 172
  • 341
-1

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.

Alon
  • 4,862
  • 19
  • 27
  • 1
    A static analysis tool can detect changing the return type of a function, adding virtual keyword to an existing member function, changing the types of function parameters, adding members to a class which is instantiable to the stack. All these break the binary backwards-compatibility. So, I disagree. A static analyzer can help to detect ABI breaks. – okun Dec 28 '09 at 15:47
  • I have to disagree: for example , a static analyzer will detect that a function return value is a structure say with integer elements a,b. while examining the source code the static analyzer cannot possible know if the compiler will set the structure in memory as {a , b} or {b, a} , its still the same structure but different ABI schemes – Alon Dec 28 '09 at 15:56
  • 1
    I *think* the OP refers to giving this theoretical tool an older and newer version of the same header file, and the tool would say whether or not changes in the newer version would mean that the library compiled with the older version is no longer good to use with the newer header. – Jim Buck Dec 28 '09 at 16:04
  • 1
    You are correct, a static analysis tool has not enough information to detect all breaks, but it can detect, if the return value has been changed e.g. from char to int. And I prefer finding out these obvious errors already during compile-time rather than later. – okun Dec 28 '09 at 16:05
  • I don't know of such a tool, but it sounds like it would be immensely useful for library/dll writers. If the tool doesn't exist, perhaps there is a business opportunity for someone. :) – Jim Buck Dec 28 '09 at 16:16
  • 1
    If your ABI changes, you have to recompile the app. If the headers didn't change, the recompiled app would be identical. Hence, if your ABI breaks, your headers definitely changed. – Nicolás Dec 29 '09 at 03:29