Re: Abidiff caveats questions.

Re: Abidiff caveats questions.

[Dodji Seketeli]

Hello,

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

[...]

> $ abidw libtirpc.so > libtirpc.so.abi
> $ abidiff libtirpc.so.abi libc-2.20.so
>
>  abidiff: /home/max/src/libabigail/src/abg-reader.cc:203: void
> abigail::xml_reader::read_context::map_id_and_node(const string&,
> xmlNodePtr): Assertion `is_ok' failed.

This is a bug in libabigail, for sure.  Sorry about that.  If I have
more information I'll work on fixing it right away.

> Quick analysis showed, that abidiff deals with 'enum-decl' here, I'm
> going to file a bug to bugzilla soon.

Thanks.  Please just attach the two binaries (libtirpc.so and
libc-2.20.so) that you are using to the bug you file and I'll work from
there.

Cheers,

> Thank you,

Thank *you* for trying abidiff out.

Cheers,

-- 
		Dodji

Re: Abidiff caveats questions.

[Maxim Ostapenko]

>> 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.
>
Dodji, thank you for your suggestion. Unfortunately this doesn't work 
for me, I've ran to the such issue:

$ abidw libtirpc.so > libtirpc.so.abi
$ abidiff libtirpc.so.abi libc-2.20.so

  abidiff: /home/max/src/libabigail/src/abg-reader.cc:203: void 
abigail::xml_reader::read_context::map_id_and_node(const string&, 
xmlNodePtr): Assertion `is_ok' failed.

Quick analysis showed, that abidiff deals with 'enum-decl' here, I'm 
going to file a bug to bugzilla soon.

Thank you,
Maxim

Abidiff caveats questions.

[Maxim Ostapenko]

Hi Dodji,

I found abidiff tool to be very useful, thank you! But it has some 
limitations and I would like to ask a few questions, is this a correct 
place to do it?

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.

I think this usecase is not widely spread, but is there any way abidiff 
could resolve this issue (perhaps resolve versioned symbol somehow)?

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:

$ cat -n test-v0.cc
          1      // Compile this with:
          2      //   g++ -g -Wall -shared -o libtest-v0.so test-v0.cc
          3
          4      struct S0
          5      {
          6        int m0;
          7      };
          8
          9      inline void
         10      foo(S0& /*parameter_name*/)
         11      {
         12        // do something with parameter_name.
         13      }
$
$ cat -n test-v1.cc
          1      // Compile this with:
          2      //   g++ -g -Wall -shared -o libtest-v1.so test-v1.cc
          3
          4      struct S0
          5      {
          6        char inserted_member;
          7        int m0;
          8      };
          9
         10      inline void
         11      foo(S0& /*parameter_name*/)
         12      {
         13        // do something with parameter_name.
         14      }

$ g++ -g -Wall -shared -o libtest-v0.so test-v0.cc
$ g++ -g -Wall -shared -o libtest-v1.so test-v1.cc
$
$ ../build/tools/abidiff libtest-v0.so libtest-v1.so
$
$ readelf -s libtest-v0.so

Symbol table '.dynsym' contains 12 entries:
    Num:    Value          Size Type    Bind   Vis      Ndx Name
      0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
      1: 0000000000000490     0 SECTION LOCAL  DEFAULT    7
      2: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __cxa_finalize
      3: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND 
_ITM_registerTMCloneTable
      4: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND 
_ITM_deregisterTMCloneTab
      5: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND 
_Jv_RegisterClasses
      6: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
      7: 0000000000201030     0 NOTYPE  GLOBAL DEFAULT   18 _edata
      8: 0000000000201038     0 NOTYPE  GLOBAL DEFAULT   19 _end
      9: 0000000000000490     0 FUNC    GLOBAL DEFAULT    7 _init
     10: 0000000000201030     0 NOTYPE  GLOBAL DEFAULT   19 __bss_start
     11: 00000000000005c8     0 FUNC    GLOBAL DEFAULT   10 _fini

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

Thank you,
Maxim

Re: Abidiff caveats questions.

[Dodji Seketeli]

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