From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68695 invoked by alias); 27 Jul 2017 09:03:04 -0000 Mailing-List: contact libabigail-help@sourceware.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Id: List-Subscribe: Sender: libabigail-owner@sourceware.org Received: (qmail 53324 invoked by uid 48); 27 Jul 2017 09:01:13 -0000 From: "dodji at redhat dot com" 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: dodji 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: bug_status Message-ID: In-Reply-To: References: 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/msg00036.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D21843 dodji at redhat dot com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #4 from dodji at redhat dot com --- > 1 Changed variable: >=20 > [C]'std::vector > 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 >' at > stl_vector.h:74:1 changed: > type size hasn't changed > 1 data member change: > type of 'std::_Vector_base > >::_Vector_impl std::_Vector_base >::_M_impl' > changed: > type size hasn't changed > 3 data member changes: > type of 'std::_Vector_base >::point= er > std::_Vector_base >::_Vector_impl::_M_start' > changed: > underlying type 'typedef > __gnu_cxx::__alloc_traits >::pointer' at > alloc_traits.h:120:1 changed: > underlying type 'typedef > std::allocator_traits >::pointer' at allocator.h:113:1 > changed: [...] typedef name changed from > std::allocator_traits >::pointer to > std::allocator::pointer at allocator.h:113:1 >=20 [...] > To me this looks like: > 1) libabigail is confused and is mistaking one type for another Hmmh, I think it's just that libabigail is not going further enough in the analysis. I think there is a typedef name change, but it doesn't change the leaf underlying type of the typedef. In both cases, the typedef is for an 'int'= .=20 And that is what libabigail isn't taking into account. So let's look at the DWARF of clang: First, the typedef __gnu_cxx::__alloc_traits >::pointe= r is=20 is represented by this DWARF: [ 8f0] typedef type (ref4) [ 793] name (strp) "pointer" So the underlying type of __gnu_cxx::__alloc_traits >::pointer is the type represented by the DIE 0x793. And that DIE 0x793 is actually std::allocator::pointer, as we can see here at: [ 74c] class_type name (strp) "allocator" byte_size (data1) 1 decl_file (data1) 4 decl_line (data1) 108 [...] [ 793] typedef type (ref4) [ b04] name (strp) "pointer" In GCC though, the typedef __gnu_cxx::__alloc_traits >::pointer is is represented by this DWARF: [ 1353] structure_type name (strp) "__alloc_traits >" byte_size (data1) 1 decl_file (data1) 16 decl_line (data1) 50 sibling (ref4) [ 1454] [...] [ 138a] typedef name (strp) "pointer" decl_file (data1) 16 decl_line (data1) 59 type (ref4) [ 43a] [ 410] structure_type name (strp) "allocator_traits >" byte_size (data1) 1 decl_file (data1) 4 decl_line (data2) 384 sibling (ref4) [ 50b] [...] [ 43a] typedef name (strp) "pointer" decl_file (data1) 4=20=20 decl_line (data2) 392 type (ref4) [ 16c6] So in GCC, the underlying type of the typedef __gnu_cxx::__alloc_traits >::pointer is "allocator_traits >::pointer". Note the difference in *typedef name* with clang. With clang, the underlyi= ng type of __gnu_cxx::__alloc_traits >::pointer is std::allocator::pointer. So libabigail is saying that "allocator_traits >::point= er" is a different typedef *name*, compared to "std::allocator::pointer". What it's failing to see is that both typedefs end up being just "int". --=20 You are receiving this mail because: You are on the CC list for the bug.