[Bug default/19638] Different output for abidiff a.xml b.xml and abidiff a.xml b.so

["dodji at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #4 from dodji at redhat dot com ---
OK, I think I understand what is happening with respect to the "added
functions" discrepancy.  I think it's Libabigail that "forgets" how some
function representation (provided by DWARF) relate to the address of some
symbols (provided by the ELF symbol table).  This loss of information happens
at type canonicalization time.  I think I probably have a fix for this.

Now I am looking at the discrepancy with respected to the "changed functions"
section.

So, in the .so file that was build with -O2 -g (the one you provided the base
abi dump for), a compiler optimization resulted in these two functions to have
their function symbols be aliases:

unity::scopes::ConfigException::ConfigException(const std::string&)

and 

unity::scopes::ConfigException::ConfigException(const
unity::scopes::ConfigException&)


Their respective symbols are
_ZN5unity6scopes15ConfigExceptionC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE

and 

_ZN5unity6scopes15ConfigExceptionC2ERKS1_.

The fact that these symbols are aliases is represented in the abi dump by the
following xml element:

    <elf-symbol
name='_ZN5unity6scopes15ConfigExceptionC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE'
type='func-type' binding='global-binding'
alias='_ZN5unity6scopes15ConfigExceptionC2ERKS1_' is-defined='yes'/>

I believe Libabigail is thus being tricked by how DWARF represents the copy
constructor ConfigException(const ConfigException&), in light of this
optimization:

Here is what libabigail sees from DWARF (and ELF):


<function-decl name='ConfigException'
mangled-name='_ZN5unity6scopes15ConfigExceptionC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE'
filepath='/build/unity-scopes-api-CnWggJ/unity-scopes-api-1.0.3+16.04.20160210.5/include/unity/scopes/ScopeExceptions.h'
line='140' column='1' visibility='default' binding='global' size-in-bits='64'
elf-symbol-id='_ZN5unity6scopes15ConfigExceptionC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE'>
[...]

See how the mangled name of the copy constructor is said to be
_ZN5unity6scopes15ConfigExceptionC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE.
 It should be 
_ZN5unity6scopes15ConfigExceptionC2ERKS1_, but then, as these two symbols are
the same, well, the compiler is right to emit debug info that says this!

But then, as a result, libabigail is comparing the function
ConfigException(const ConfigException&) from the old library, with the function
ConfigException(const string&) from the new library.  And it's (rightfully)
saying that parameter 'const ConfigException&' was changed to parameter 'const
string&' !

Why?

Because, the symbol of ConfigException(const ConfigException&) in the old
library is
_ZN5unity6scopes15ConfigExceptionC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
(an alias of _ZN5unity6scopes15ConfigExceptionC2ERKS1_) and the symbol of
ConfigException(const string&) in the new library has the same symbol!

So, libabigail does its job of also comparing the *types* of these symbols. 
And indeed, the ABI of the first build is different from the ABI of the second
build, though, not in an incompatible way.

Now to understand the reason why comparing the two ABI dumps is different from
comparing one ABI dump against the later DSO, I think I would need to get my
hand on the .so file compiled with -g -O2.  It doesn't have to be exactly the
same as the one you provided here, though.  It "just" have to contain the code
of the ConfigException constructors which exhibits the compiler optimization I
talked about.

Thanks.

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