Stable library ABI compatibility checking

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

Hello,

Last things first, some examples:

http://xenbits.xen.org/people/andrewcoop/abi/libxenevtchn-1.1_to_1.2.html
http://xenbits.xen.org/people/andrewcoop/abi/libxenforeignmemory-1.3_to_1.4.html

These are an ABI compatibility report between RELEASE-4.14.0 and staging.

They're performed with abi-dumper (takes a shared object and header
file(s) and write out a text "dump" file which happens to be a perl
hash) and abi-compliance-checker checker, which takes two dumps and
produces the HTML reports linked above.  They're both debian tools
originally, but have found their way across the ecosystem.  They have no
impact on build time (when invoked correctly).

I'm encouraged to see that the foreignmem analysis has even spotted that
we deliberately renamed one parameter to clarify its purpose.


For the stable libraries, the RELEASE-$X.$Y.0 tag is the formal point
when accumulated changes in staging become fixed.  What we ought to be
doing is taking a "dump" of libraries at this point, and publishing
them, probably on xenbits.

Subsequent builds on all the staging branches should be performing an
ABI check against the appropriate lib version.  This will let us catch
breakages in staging (c/s e8af54084586f4) as well as breakages if we
ever need to backport changes to the libs.

For libraries wrapped by Juergen's tools/libs/ common-makefile changes,
adding ABI dumping is easy.  The only complicating is needing to build
everything with "-Og -g", but this is easy to arrange, and frankly ought
to be the default for debug builds anyway (the current use of -O0 is
silly and interferes with common distro hardening settings).

What I propose is tweaking the library build to write out
lib$FOO.so.$X.$Y-$(ARCH).abi.dump files.  A pristine set of these should
be put somewhere on xenbits, and a task put on the release technicians
checklist for future releases.

That way, subsequent builds which have these tools available can include
a call to abi-compliance-checker between the authoritative copy and the
one from the local build, which will make the report available, and exit
nonzero on breaking problems.


To make the pristine set, I need to retrofit the tooling to 4.14 and
ideally 4.13.  This is in contravention to our normal policy of not
backporting features, but I think, being optional build-time-only
tooling, it is worthy of an exception considering the gains we get
(specifically - to be able to check for ABI breakages on these branches
in OSSTest).  Backporting to 4.12 and older is far more invasive, due to
it being before the library build systems were common'd.


Anyway, thoughts?

~Andrew