Re: Abidiff caveats questions.

[Dodji Seketeli <dodji@redhat.com>]

Maxim Ostapenko <m.ostapenko@partner.samsung.com> a Ãcrit:

> Hi Dodji,

Hello Maxim,

> I found abidiff tool to be very useful, thank you!

Thanks!

> But it has some limitations and I would like to ask a few questions,
> is this a correct place to do it?

Sure, this mailing list is the right place to ask.

> 1) Abidiff works great with different versions of one shared library
> (I used glibc 2.20 and glibc 2.18), but it was confused when I tried
> to compare libc-2.20.so with libtirpc.so to find ABI incompatibilities
> between Glibc and Libtirpc RPC implementations. Since Glibc has
> versioned symbols (for example authunix_create@@GLIBC_2.2.5) and
> Libtirpc has non-versioned ones (authunix_create), abidiff confuses to
> compare them (and their parameters types), so we have no detailed
> information about changes happened, only that first symbol was deleted
> and second was added.

Well, it was not confused.  This is the intended way of working.

Two symbols that have different versions are different symbols.  So if a
function F1 has an underlying ELF symbol that is different from the
symbol of function F2, then F1 and F2 are considered as being different
functions.  For F1 and F2 to be considered as being the same function,
they really must have the same underlying symbol name.

> I think this usecase is not widely spread,

Indeed.  We intended to compare the sub-types of functions (and
variables) which symbols haven't changed accross two versions of the
same library to detect potential ABI-incompatible changes.

> but is there any way abidiff could resolve this issue (perhaps resolve
> versioned symbol somehow)?

Not at this point, no.  But I guess one could imagine to perform some
tweaks.

For instance, you could save the ABI representation of libtirpc into the
XML format of libabigail by using the abidw tool:

    abidw libtirpc.so > libtirpc.so.abi

Then you can edit the libtirpc.so.abi file as you wish (it's an XML
file), by changing the symbol version there (for instance, by saying
that it has a GLIBC_2.2.5 version, for instance).  Then when you are
done, you can compare that modified libtirpc.so.abi with libc-2.20.so by
doing:

    abidiff libtirpc.so.abi libc-2.20.so

I believe that should work.  If not, then there is a bug in there that
should be fixed.

> 2) I tried the second example from abidiff manual
> (https://sourceware.org/libabigail/manual/abidiff.html) with the small
> change: I've made function foo inline.
> Abidiff didn't detected any ABI changes that is expected, because G++
> didn't generate corresponding symbol in .dynsym section:

[...]

> Perhaps abidiff documentation should point out that users shouldn't
> expect much, if they use inline functions widely?

Yes, you are right.  We should add that to the documentation, you are
right.

Cheers,

-- 
		Dodji