Re: Stable library ABI compatibility checking

[Jan Beulich <jbeulich@xxxxxxxx>]

On 11.02.2021 12:30, Andrew Cooper wrote:
> On 11/02/2021 11:05, Jan Beulich wrote:
>> On 11.02.2021 02:08, Andrew Cooper wrote:
>>> 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?
>> +1
>>
>> Not sure about the backporting effects - tools/libs/ had quite a bit
>> less content in 4.14 and older, so the coverage would be smaller.
> 
> tools/libs/ has been the stable libraries, since IanC split them years
> ago.  The only odd-one-out is libxenstored IIRC, which moved during the
> 4.15 window.

As well as ctrl/, guest/, light/, stat/, util/, and vchan/.

Jan