Re: idea: abigail abixml archive

[Dodji Seketeli <dodji@seketeli.org>]

Hello,

[...]

Dodji Seketeli <dodji@seketeli.org> writes:

>> Today, even if you have access to the target distro, it's not practical
>> with the current tools to know if the binary is "ABI compatible" with
>> it.
>>
>> If I understand things correctly, you would need to:
>>
>>     1/ Get the ABI of the (transitive closure) set of dependencies of
>>     the binary on its original distro.  I call it orig-deps-abi.
>>     2/ Get the ABI of the set of dependencies of the binary on the
>>     target distro.  I call it target-deps-abi.
>>     3/ compare target-deps-abi against orig-deps-abi.

fche@redhat.com (Frank Ch. Eigler) a écrit:

> Heck, if we're just testing binary A against the remote shared
> libraries B C D, then the local libraries B C D may not be relevant at
> all.

I think it all boils down to what we mean by "testing binary A against
its dependency".

When we want to know if a binary A is compatible with a library B, we
consider functions & global variables undefined in A and defined (and
exported) in B.  The DWARF for the types of the undefined functions &
variables are present in A.  These are the types "expected" by A.  In B,
there is going to be same types, because they come with the definition
of the exported functions & variables that are expected by A.  So these
types are "provided" by B.

We can compare the types expected by A to their counterpart provided by
B and if they are equal, then A is compatible with B, as far as these
functions & variables and their types are concerned.

This is basically what abicompat does.

But then there is a case of incompatibility that we can't catch by
looking at just A and B.  That is, if a function that was previously
defined in B (and is needed by A) is removed from B.  In that case, we
need to know if that function was moved to another dependency of A.  It
only is if the function is removed from all the dependencies of A that
we can know for sure that the function is missing, and thus, that A is
facing an incompatible change in that regard.

>  Is the transitive closure necessary?

I think the transitive closure would be necessary for the case I
explained above, because a removed function could have been moved to any
other dependant library.  Or am I missing something?

> If so, then it's just comparing the local binary A vs. the
> directly dependentent remote libraries mentioned in DT_NEEDED.

If you only want to consider the dependant remote dependencies, then
that would amount to doing what abicompat does today, more or less.  I
think that could work too (instead of going through [1-3]).  The only
caveat I would have is the transitive closure one.

[...]


fche@redhat.com (Frank Ch. Eigler) a écrit:

>>> To keep it dead simple, there could be one branch per /etc/os-release
>>> $ID/$VERSION_ID, one file per shared library in the distribution.  For
>>> example, a fedora-39-x86-64 copy of /usr/lib64/libc.so.6, the file
>>> abidw produces could sit at
>>>
>>>    repo  git://sourceware.org/git/libabigail.git 
>>>  branch  gitabixml/fedora/39/x86_64
>>>    file  /usr/lib64/libc.so.6.xml

Dodji Seketeli <dodji@seketeli.org> writes:

>>
>> I would even go further as to put the binary inside a subdirectory tree
>> with all that information, making it somewhat independent from being in git:

fche@redhat.com (Frank Ch. Eigler) a écrit:

> hmm

>>>    repo  git://sourceware.org/git/distributions-abi.git
>>>    file  /fedora/39/x86_64/glibc/usr/lib64/libc.so.6.xml
>             ^^^^^^^^^^^^^^^^^^#####
>
> While the ^^^^ first part can be known to the client, the #### package
> abbreviation may well not be.  A binary just makes reference to sonames,
> which are only roughly file names, and definitely not package
> abbreviations.

Indeed, not all binary present on the user's system come from a package.
And the ABI of those binaries might indeed end up in the repository.
Point taken.

OK then, I take the package thing back.

Let's just store the thing in Git as you proposed.

[...]


>> Also, we need to add a mode to libabigail to let it expect debuginfod
>> to find the debuginfo because today, it expects the user to provide
>> the debug info location in cases where it's not already installed on
>> the system.  [...]
>
> Are you sure?  I run libabigail tools without any manual -d type
> settings or debuginfod overrides, and it already just works, via
> elfutils' builtin debuginfod support.
>

Interesting.  I must double check.  I must have broken something locally
then.  I am pretty sure to remember I've had to add the --d{1,2} to
abipkgdiff otherwise it wasn't finding debuginfo.  But I need to double
check.  It it works that's great :-)

Cheers,

-- 
		Dodji