[Bug default/21492] New: string comparison of class name from DWARF leads to false ABI incompatibility report

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

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

            Bug ID: 21492
           Summary: string comparison of class name from DWARF leads to
                    false ABI incompatibility report
           Product: libabigail
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: default
          Assignee: dodji at redhat dot com
          Reporter: woodard at redhat dot com
                CC: libabigail at sourceware dot org
  Target Milestone: ---

I was taking a little time to work on my sometime project of inter-compiler ABI
compatibility and I ran libabigail a nice bit of C++ code through both clang
and gcc

doing:
$ abidiff ./src/abg-sptr-utils.o ../build-llvl/src/abg-sptr-utils.o

Functions changes summary: 0 Removed, 1 Changed (1 filtered out), 0 Added
function
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

1 function with some indirect sub-type change:

  [C]'function abigail::sptr_utils::regex_t_sptr
abigail::sptr_utils::build_sptr<re_pattern_buffer>()' at abg-sptr-utils.cc:54:1
has some indirect sub-type changes:
    return type changed:
      underlying type 'class std::tr1::shared_ptr<re_pattern_buffer>' at
shared_ptr.h:983:1 changed:
        type size hasn't changed
        1 base class deletion:
          class std::tr1::__shared_ptr<re_pattern_buffer,
(__gnu_cxx::_Lock_policy)2u> at shared_ptr.h:539:1
        1 base class insertion:
          class std::tr1::__shared_ptr<re_pattern_buffer,
__gnu_cxx::_Lock_policy::_S_atomic> at shared_ptr.h:539:1

GCC seems to provide a name which is what libabigail prints and not much else
about the base class that changed:
 [  1002]        class_type
                 name                 (strp) "__shared_ptr<re_pattern_buffer,
(__gnu_cxx::_Lock_policy)2u>"
                 byte_size            (data1) 16
                 decl_file            (data1) 1
                 decl_line            (data2) 539
                 sibling              (ref4) [  11b3]

These end up being the same thing and so there is no ABI class change.

With both compilers the symbol looks like:

_ZTISt12__shared_ptrIiLN9__gnu_cxx12_Lock_policyE2EE

So this is an abigail issue. We either need to get GCC and Clang to
agree on the strings in their debuginfo (unlikely to happen), or
abigail needs to be smarter about comparing them. 

Would it be possible to extend the logic to do a 2nd check when the names don't
match and compare the linkage names which are the same. Since the linkage names
are the same and the type info is included in the linkage name, you may be able
to weed out the false positives in C++ code such as this.

If that won't work can we add a new kind of support for this in the suppression
specification infrastructure and then provide a default suppression for this.

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