[Bug default/29733] New: Comparing 2.0 dump to 2.1 dump: parameter 1 of type 'int' was added to destructor

[Bug default/29733] New: Comparing 2.0 dump to 2.1 dump: parameter 1 of type 'int' was added to destructor

[dermojo at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29733

            Bug ID: 29733
           Summary: Comparing 2.0 dump to 2.1 dump: parameter 1 of type
                    'int' was added to destructor
           Product: libabigail
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: default
          Assignee: dodji at redhat dot com
          Reporter: dermojo at gmail dot com
                CC: libabigail at sourceware dot org
  Target Milestone: ---

Created attachment 14423
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14423&action=edit
sample library code

Hi,

I'm storing ABI dumps together with my shared library (C++) to check for ABI
breaks when rebuilding. I found an incompatibility when upgrading libabigail
and its tools from 2.0 to 2.1:

The exact same code yields different ABI dumps between both versions, and
abidiff reports incompatible changes, For example, the attached sample shows
this (compiled with "g++ -shared -o libsample.so sample.cpp -Wall -std=c++11 -g
-ggdb"):

> $ ~/git/libabigail-2.1/build/tools/abidiff abi-2.0.dump abi-2.1.dump
> Functions changes summary: 0 Removed, 1 Changed, 0 Added function
> Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
> 
> 1 function with some indirect sub-type change:
> 
>   [C] 'method Sample::~Sample()' at sample.cpp:2:1 has some indirect sub-type changes:
>     parameter 1 of type 'int' was added
> 
> (exit code: 4)

Comparing the ABI dumps between version 2.0 and 2.1, I can see that the 2.0
dump only contains 1 destructor as member function (_ZN6SampleD2Ev), while the
2. dump contains an additional _ZN6SampleD4Ev and both have the additional
"int" parameter.

The library symbol table doesn't contain _ZN6SampleD4Ev, only the debug info
does, and AFAIS only the D4 destructor has the additional int parameter.

Any help to resolve this is highly appreitated.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/29733] Comparing 2.0 dump to 2.1 dump: parameter 1 of type 'int' was added to destructor

[dermojo at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29733

--- Comment #1 from Daniel Evers <dermojo at gmail dot com> ---
Created attachment 14424
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14424&action=edit
ABI dump from version 2.0

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/29733] Comparing 2.0 dump to 2.1 dump: parameter 1 of type 'int' was added to destructor

[dermojo at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29733

--- Comment #2 from Daniel Evers <dermojo at gmail dot com> ---
Created attachment 14425
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14425&action=edit
ABI dump from version 2.1

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/29733] Comparing 2.0 dump to 2.1 dump: parameter 1 of type 'int' was added to destructor

[dodji at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29733

dodji at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |NOTABUG
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #3 from dodji at redhat dot com ---
Hello,

I think the behaviour you are seeing is due to this commit that happened in the
2.1 version, indeed:

https://sourceware.org/git/?p=libabigail.git;a=commit;h=861e4670b611b2f95d69f68bb1edaa15ab5f3aa5.

Long story short, that commit introduced a (minor) incompatibility in the abi
dumps due to a fix in the handling of cloned functions.  Cloned functions is
how some compilers (like GCC) handle the implementation of the different kinds
of destructor functions.  With that fix, libabigail better represents all
cloned functions in its IR. That is why you are seeing more destructors in the
ABI dump.

I bumped the version number of ABIXML to say that users, like yourself, who
rely on abi dumps need to re-generate those dumps with the new version of
libabigail if they want to perform comparisons of the dumps, as opposed to
comparing the binaries directly.

So, long story even shorter, I think the solution would be to regenerate the
dumps with the 2.1 version.  I try to avoid those abixml version bumps, but
sometimes they are necessary, sadly.

Sorry for the inconvenience.

-- 
You are receiving this mail because:
You are on the CC list for the bug.