From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libabigail-return-1095-listarch-libabigail=sourceware.org@sourceware.org>
Received: (qmail 85845 invoked by alias); 27 Jul 2017 14:33:05 -0000
Mailing-List: contact libabigail-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:libabigail@sourceware.org>
List-Help: <mailto:libabigail-help@sourceware.org>
List-Id: <libabigail.sourceware.org>
List-Subscribe: <mailto:libabigail-subscribe@sourceware.org>
Sender: libabigail-owner@sourceware.org
Received: (qmail 85678 invoked by uid 48); 27 Jul 2017 14:33:00 -0000
From: "woodard at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: libabigail@sourceware.org
Subject: [Bug default/21843] libabigail not correctly keeping track of nested scopes for typedefs
Date: Sun, 01 Jan 2017 00:00:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: libabigail
X-Bugzilla-Component: default
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: woodard at redhat dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: dodji at redhat dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-21843-9487-c8dc1cvDxI@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21843-9487@http.sourceware.org/bugzilla/>
References: <bug-21843-9487@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-q3/txt/msg00037.txt.bz2

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

--- Comment #5 from Ben Woodard <woodard at redhat dot com> ---
I'm still not convinced that libabigail is looking at the same structures h=
ere.
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_im=
pl
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' chang=
ed:
               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=3D'public' layout-offset-in-bits=3D'0'>
              <!-- std::_Vector_base<int, std::allocator<int> >::pointer
std::_Vector_base<int, std::allocator<int> >::_Vector_impl::_M_start -->
              <var-decl name=3D'_M_start' type-id=3D'type-id-25'
visibility=3D'default' filepath=3D'/usr/include/c++/7/bits/stl_vector.h' li=
ne=3D'84'
column=3D'1'/>
            </data-member>

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

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

Then you look at the abidw output from clang:

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

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

So it looks to me like libabigail is processing the DWARF correctly but dur=
ing
the comparison phase. It seems like it is pulling a typedef of "pointer" fr=
om a
different nested scope.

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