Re: [Bug default/31513] abidiff differences due to change in compiler version

[Dodji Seketeli <dodji@seketeli.org>]

Hello,

> Attached the required libraries.

Thanks!  These have been really useful.

So here is my analysis, looking at the debug info.

I think it all boils down to a change in the implementation details of
the vector type of the standard library.  Namely, the type:
    _Vector_base<char, std::allocator<char> >::_Vector_impl.

Let's look at a dump of the DWARF debuginfo for that type in the binary
resulting from the libstdc++ implementation for gcc7.xx:


     [  2c03]        structure_type       abbrev: 17
                     name                 (strp) "_Vector_impl"
                     byte_size            (data1) 24
                     decl_file            (data1) stl_vector.h (3)
                     decl_line            (data1) 81
                     sibling              (ref4) [  2cc5]
     [  2c0f]          inheritance          abbrev: 59
                       type                 (ref4) [  2540]
                       data_member_location (data1) 0
     [  2c15]          member               abbrev: 7
                       name                 (strp) "_M_start"
                       decl_file            (data1) stl_vector.h (3)
                       decl_line            (data1) 84
                       type                 (ref4) [  2cc5]
                       data_member_location (data1) 0
     [  2c21]          member               abbrev: 7
                       name                 (strp) "_M_finish"
                       decl_file            (data1) stl_vector.h (3)
                       decl_line            (data1) 85
                       type                 (ref4) [  2cc5]
                       data_member_location (data1) 8
     [  2c2d]          member               abbrev: 7
                       name                 (strp) "_M_end_of_storage"
                       decl_file            (data1) stl_vector.h (3)
                       decl_line            (data1) 86
                       type                 (ref4) [  2cc5]
                       data_member_location (data1) 16
     [...]


So we see that the _Vector_impl type inherits a type identified by the
DIE (debug information entry) at offset 0x2540 (which happens to be the
type allocator<char>) and has three data members: _M_start, _M_finish,
and _M_end_of_storage.


Now, let's look at the similar dump of the DWARF debuginfo for that type
in the binary resulting from the libstdc++ implementation for gcc11.xx:


     [  36b3]        structure_type       abbrev: 23
                     name                 (strp) "_Vector_impl"
                     byte_size            (data1) 24
                     decl_file            (data1) stl_vector.h (3)
                     decl_line            (data1) 128
                     decl_column          (data1) 14
                     sibling              (ref4) [  377e]
     [  36c0]          inheritance          abbrev: 50
                       type                 (ref4) [   bb5]
                       data_member_location (implicit_const) 0
     [  36c5]          inheritance          abbrev: 50
                       type                 (ref4) [  35f9]
                       data_member_location (implicit_const) 0
     [  36ca]          subprogram           abbrev: 24
                       external             (flag_present) yes
                       name                 (strp) "_Vector_impl"
                       decl_file            (data1) stl_vector.h (3)
                       decl_line            (data1) 131
                       decl_column          (data1) 2
                       linkage_name         (strp) "_ZNSt12_Vector_baseIcSaIcEE12_Vector_implC4Ev"
                       declaration          (flag_present) yes
                       object_pointer       (ref4) [  36de]
                       sibling              (ref4) [  36e4]
     [  36de]            formal_parameter     abbrev: 2
                         type                 (ref4) [  6bce]
                         artificial           (flag_present) yes
     [  36e4]          subprogram           abbrev: 24

     [...]

Here, we see that the _Vector_impl inherits *TWO* types.  One is
identified by the DIE at offset 0xbb5 (which is the type
allocator<char>) and the other is the type identified by the DIE at
offset 0x35f9 which the (newly introduced) type:

    "_Vector_base<char, std::allocator<char> >::_Vector_impl_data"

And we see that this new implementation of _Vector_impl doesn't have any
of the data members _M_start, _M_finish,  _M_end_of_storage.  Now let's
look at the DIE for the type:

    "_Vector_base<char, std::allocator<char> >::_Vector_impl_data"


 [  35f9]        structure_type       abbrev: 23
                 name                 (strp) "_Vector_impl_data"
                 byte_size            (data1) 24
                 decl_file            (data1) stl_vector.h (3)
                 decl_line            (data1) 91
                 decl_column          (data1) 14
                 sibling              (ref4) [  36a2]
 [  3606]          member               abbrev: 6
                   name                 (strp) "_M_start"
                   decl_file            (data1) stl_vector.h (3)
                   decl_line            (data1) 93
                   decl_column          (data1) 10
                   type                 (ref4) [  36a7]
                   data_member_location (data1) 0
 [  3613]          member               abbrev: 6
                   name                 (strp) "_M_finish"
                   decl_file            (data1) stl_vector.h (3)
                   decl_line            (data1) 94
                   decl_column          (data1) 10
                   type                 (ref4) [  36a7]
                   data_member_location (data1) 8
 [  3620]          member               abbrev: 6
                   name                 (strp) "_M_end_of_storage"
                   decl_file            (data1) stl_vector.h (3)
                   decl_line            (data1) 95
                   decl_column          (data1) 10
                   type                 (ref4) [  36a7]
                   data_member_location (data1) 16
 [...]
 

We see that this new type has the three data members _M_start,
_M_finish,  _M_end_of_storage that are missing from _Vector_impl.

In other words, the data members of the class _Vector_impl in gcc7 were moved to
the class _Vector_impl_data in gcc11 and _Vector_impl now inherits
_V_Vector_impl_data.

Note that the layout of the _Vector_impl hasn't changed.  Its size
hasn't changed either.  This is coherent with what abidiff says, when it
says that the size hasn't changed (and when it doesn't report any offset change):

                  type of 'std::_Vector_base<char, std::allocator<char> >::_Vector_impl _M_impl' changed:
                    type size hasn't changed
                    1 base class insertion:
                      struct std::_Vector_base<char, std::allocator<char> >::_Vector_impl_data at stl_vector.h:91:1
                    3 data member deletions:
                      'std::_Vector_base<char, std::allocator<char> >::pointer _M_start', at offset 0 (in bits) at stl_vector.h:84:1
                      'std::_Vector_base<char, std::allocator<char> >::pointer _M_finish', at offset 64 (in bits) at stl_vector.h:85:1
                      'std::_Vector_base<char, std::allocator<char> >::pointer _M_end_of_storage', at offset 128 (in bits) at stl_vector.h:86:1


In other words, this is not an incompatible ABI change.  I'd argue that
it's not even an ABI change.

Now, I am thinking that *maybe* we should make libabigail detect that
the data members _M_start, _M_finish and _M_end_of_storage were moved to
the new base class _Vector_impl_data with no observable change to the
layout of the _Vector_impl class.  This would have made the analysis
much simpler for the user.  What do you think?  If you agree, then I
think we should add a new enhancement request for that feature.

> Ques 1: Is this behavior expected as we have not made any change in the source
> files of the library the highlighted changes are in compiler source files.

I guess I would answer "it depends".  Sorry.

This is a real change that happened in the implementation details of the
libstdc++ standard library.  If, for a reason, you are interested in
reviewing this kind of changes you might be interested in *seeing* them
in the first place.

If, on the other hand, you are not interested in the changes about types
(that are implementation details) of the libstdc++ standard library,
then yes, these changes should be suppressed from the output of
abidiff.  You should be able to control this behavior, I think.


> Ques 2: If yes, can you share a suppression file to ignore all the
> changes which are not from the elf source file.

So, here is an example of suppression file that you could use, if you
want to suppress all the changes to the types of the "std" namespace:

---------->8<---------------------
[suppress_type]
  # Suppress changes in types of the std:: namespace
  name_regexp = ^std::.*
--------->8<----------------------

For the record, here is what I am getting when using a suppression file
with that content:


        $ cat default.suppr
        [suppress_type]
          # Suppress changes in types of the std:: namespace
          name_regexp = ^std::.*

        $ abidiff --suppr default.suppr bin/libloremipsum_gcc7.so bin/libloremipsum_gcc11.so
        Functions changes summary: 16 Removed, 0 Changed (20 filtered out), 21 Added functions
        Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
        Function symbols changes summary: 2 Removed, 2 Added function symbols not referenced by debug info
        Variable symbols changes summary: 0 Removed, 0 Added variable symbol not referenced by debug info

        [...]
        $

Note how all the *type changes* got filtered out, as shown in the summary.

I hope this helps.

-- 
		Dodji