Checking the ABI of packages submitted to the updates-testing Fedora repository

[Dodji Seketeli]

> On Fri, 2015-06-05 at 10:34 +0200, Dodji Seketeli wrote:

[...]

>> To start, we'd like to have an automated way to check the ABI
>> compatibility of binaries embedded in packages that are submitted to 
>> the
>> updates-testing repository.  When an incompatible change[1] is 
>> detected,
>> the package will be prevented from auto-increasing it's karma count. 

Stephen Gallagher <sgallagh at redhat.com> a écrit:

> Just to clarify, this isn't about the karma *count*, it's about whether
> a package can be pushed to stable automatically when it reaches the
> karma threshold or if it requires a conscious decision by the
> maintainer to push it. This will present backwards-incompatible changes
> from going to stable *accidentally*. (There are cases where they are
> permissible, such as security patches or ABI changes that are
> coordinated with all their consumers).

I stand corrected, thanks.

[...]

> Since it wasn't covered in the original email:
>
> This first step is limited to C and C++ ABI (basically ELF binaries).

Correct.

> Long-term, the goal would be to develop and implement ABI checking for
> a variety of other languages, but those tools are not yet readily
> available (or if they are, we don't know about them. So please educate
> us!)

:-)

Right now libabigail (and thus the tools that are built on top of it,
e.g, abidiff and abipkgdiff) only groks the ELF format, as well as it's
associated DWARF debug info format.  It understand C++ and C language
constructs necessary to express the signatures of exported functions and
variable, included the definitions of the types used in these
signatures.

In other words, it can understand that a new base class Foo was added to
the set of base classes that class Bar inherits from; and that made Foo
grow to 296 bytes.  Or it can understand that a data member of type char
was removed from struct S at offset 32, and that breaks ABI through the
use of the exported function "baz(struct S*)";

I guess those capabilities can be extended with reasonable efforts to
languages that compiles to ELF binaries, using DWARF as debug info
support.

But then for dynamically interpreted languages such as Python, I think
something similar but specific to each execution environment (one per
dynamic language) would be needed.

The nature of programs written in these dynamic languages makes it quite
hard to compare types used in the API entry points of a library, at
least compared to the the way we do it with programs written in
statically compiled languages.

This is because in the latter case, types are expressed statically and
explicitely, something like libabigail can then read their definitions
and compare them.  But in the former case, function signatures don't
necessarily express the name of the types they expect; and even if one
ends up deducing the type expected for a function parameter, that type
is not necessarily statically defined; e.g, one can inject new data
members to it, at any time in the program.

But then, even for those dynamic language, we could compare make sure,
for instance, that an exported function advertised as being an API entry
point and defined in a given version of a library doesn't disappear in
the subsequent version.  Simple things like that.

And even for these simple cases, I don't know if a tool like that exists
in Free Software.

Cheers,

-- 
		Dodji