[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug default/21843] libabigail not correctly keeping track of nested scopes for typedefs



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

--- Comment #5 from Ben Woodard <woodard at redhat dot com> ---
I'm still not convinced that libabigail is looking at the same structures here.
If we back up a little bit and begin looking from _M_start:

Functions changes summary: 0 Removed, 0 Changed, 0 Added function
Variables changes summary: 0 Removed, 1 Changed, 0 Added variable

1 Changed variable:

  [C]'std::vector<int, std::allocator<int> > var' was changed at test4.C:3:1:
    type of variable changed:
     type size hasn't changed
     1 base class change:
       'struct std::_Vector_base<int, std::allocator<int> >' at
stl_vector.h:74:1 changed:
         type size hasn't changed
         1 data member change:
          type of 'std::_Vector_base<int, std::allocator<int> >::_Vector_impl
std::_Vector_base<int, std::allocator<int> >::_M_impl' changed:
            type size hasn't changed
            3 data member changes:
             type of 'std::_Vector_base<int, std::allocator<int> >::pointer
std::_Vector_base<int, std::allocator<int> >::_Vector_impl::_M_start' changed:
               underlying type 'typedef
__gnu_cxx::__alloc_traits<std::allocator<int> >::pointer' at
alloc_traits.h:120:1 changed:
...

When you look at the output of abidw output from gcc you find:

            <data-member access='public' layout-offset-in-bits='0'>
              <!-- std::_Vector_base<int, std::allocator<int> >::pointer
std::_Vector_base<int, std::allocator<int> >::_Vector_impl::_M_start -->
              <var-decl name='_M_start' type-id='type-id-25'
visibility='default' filepath='/usr/include/c++/7/bits/stl_vector.h' line='84'
column='1'/>
            </data-member>

and look back at type-id-25 you see:

        <member-type access='public'>
          <!-- typedef std::_Vector_base<int, std::allocator<int> >::pointer
std::vector<int, std::allocator<int> >::pointer -->
          <typedef-decl name='pointer' type-id='type-id-25'
filepath='/usr/include/c++/7/bits/stl_vector.h' line='233' column='1'
id='type-id-24'/>
        </member-type>

Then you look at the abidw output from clang:

            <data-member access='public' layout-offset-in-bits='0'>
              <!-- std::_Vector_base<int, std::allocator<int> >::pointer
std::_Vector_base<int, std::allocator<int> >::_Vector_impl::_M_start -->
              <var-decl name='_M_start' type-id='type-id-22'
visibility='default'
filepath='/usr/bin/../lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/bits/stl_vector.h'
line='84' column='1'/>
            </data-member>

        <member-type access='private'>
          <!-- typedef std::_Vector_base<int, std::allocator<int> >::pointer
std::vector<int, std::allocator<int> >::pointer -->
          <typedef-decl name='pointer' type-id='type-id-22'
filepath='/usr/bin/../lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/bits/stl_vector.h'
line='233' column='1' id='type-id-21'/>
        </member-type>

So it looks to me like libabigail is processing the DWARF correctly but during
the comparison phase. It seems like it is pulling a typedef of "pointer" from a
different nested scope.

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