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

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

[woodard at redhat dot com]

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

--- Comment #3 from Ben Woodard <woodard at redhat dot com> ---
Trying to express it more clearly:
There are multiple typedefs named pointer which are specialized templates
defined within the scopes of different classes. It appears that libabigail is
getting the scopes of these typedefs confused.

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

[Bug default/21843] New: libabigail getting confused or possibly bad dwarf

[woodard at redhat dot com]

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

            Bug ID: 21843
           Summary: libabigail getting confused or possibly bad dwarf
           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: ---

Created attachment 10287
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10287&action=edit
clang object

I'm sorry if this is poorly specified. I generally try to boil them down to
either compiler DWARF generation errors or libabigail problems. In this case I
haven't been able to unravel the DWARF well enough to be able to tell.

The source code is trivial:
#include <vector>

std::vector<int> var;

When compiled with gcc and clang
g++ (GCC) 7.1.1 20170622 (Red Hat 7.1.1-3)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

ends up generating some curious errors:

[ben@localhost c++test]$ cat test4.abidiff 
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:
                 underlying type 'typedef
std::allocator_traits<std::allocator<int> >::pointer' at allocator.h:113:1
changed:
                   'typedef std::allocator_traits<std::allocator<int>
>::pointer' access changed from 'public' to 'private'
                   typedef name changed from
std::allocator_traits<std::allocator<int> >::pointer to
std::allocator<int>::pointer at allocator.h:113:1

...

The accessibility thing looks like a minor DWARF buglet by one of the
compilers. However, I have been unable to trace through the DWARF from GCC to
find the type that it refers to. I also talked to mjw and he had trouble
tracking down the underlying type as well. The challenge appears to be the way
that gcc imports modules. This makes it extremely difficult to manually track
through GCC's DWARF.

More concerning to me and why I've been spending so much time on this is:
                   typedef name changed from
std::allocator_traits<std::allocator<int> >::pointer to
std::allocator<int>::pointer at allocator.h:113:1

To me this looks like:
1) libabigail is confused and is mistaking one type for another
2) something is wrong in GCC's DWARF (which I find less likely - thus this bug)

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

[Bug default/21843] libabigail getting confused or possibly bad dwarf

[woodard at redhat dot com]

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

--- Comment #2 from Ben Woodard <woodard at redhat dot com> ---
I'm becoming increasingly convinced that it is libabigail that is going off in
the weeds here and I think it has to do with template specialization that ends
up being nothing.

when you look at the DWARF from clang and track down the specialization of
pointer in line 113
 [    2a]    variable
             name                 (strp) "var"
             type                 (ref4) [    47]
             external             (flag_present) yes
             decl_file            (data1) 6
             decl_line            (data1) 3
             location             (exprloc) 
              [   0] addr .bss+0 <var>
 [    3f]    namespace
             name                 (strp) "std"
             decl_file            (data1) 1
             decl_line            (data2) 2190
 [    47]      class_type
               name                 (strp) "vector<int, std::allocator<int> >"
               byte_size            (data1) 24
               decl_file            (data1) 5
               decl_line            (data1) 216
...
 [   74c]      class_type
               name                 (strp) "allocator<int>"
               byte_size            (data1) 1
               decl_file            (data1) 4
               decl_line            (data1) 108
...
 [   793]        typedef
                 type                 (ref4) [   b04]
                 name                 (strp) "pointer"
                 decl_file            (data1) 4
                 decl_line            (data1) 113
...
 [   b04]    pointer_type
             type                 (ref4) [   b09]
 [   b09]    base_type
             name                 (strp) "int"
             encoding             (data1) signed (5)
             byte_size            (data1) 4

So when libabigail says: 
                   typedef name changed from
std::allocator_traits<std::allocator<int> >::pointer to
std::allocator<int>::pointer at allocator.h:113:1

pointer is in the std namespace and the typedef is defined inside the
specialization of the allocator<int> class so that all makes sense.

However, when we reverse the order of the abidiff command line we get a
different error message:
[ben@localhost c++test]$ abidiff --no-unreferenced-symbols --harmless
test4-clang.o  test4-gcc.o 
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:59:1 changed:
                 underlying type 'typedef std::allocator<int>::pointer' at
alloc_traits.h:392:1 changed:
                   'typedef std::allocator<int>::pointer' access changed from
'private' to 'public'
                   typedef name changed from std::allocator<int>::pointer to
std::allocator_traits<std::allocator<int> >::pointer at alloc_traits.h:392:1


             type of 'std::_Vector_base<int, std::allocator<int> >::pointer
std::_Vector_base<int, std::allocator<int> >::_Vector_impl::_M_finish' changed:
               underlying type 'typedef
__gnu_cxx::__alloc_traits<std::allocator<int> >::pointer' at
alloc_traits.h:59:1 changed:
                 underlying type 'typedef std::allocator<int>::pointer' at
alloc_traits.h:392:1 changed:
                   'typedef std::allocator<int>::pointer' access changed from
'private' to 'public'
                   typedef name changed from std::allocator<int>::pointer to
std::allocator_traits<std::allocator<int> >::pointer at alloc_traits.h:392:1


             type of 'std::_Vector_base<int, std::allocator<int> >::pointer
std::_Vector_base<int, std::allocator<int> >::_Vector_impl::_M_end_of_storage'
changed:
               underlying type 'typedef
__gnu_cxx::__alloc_traits<std::allocator<int> >::pointer' at
alloc_traits.h:59:1 changed:
                 underlying type 'typedef std::allocator<int>::pointer' at
alloc_traits.h:392:1 changed:
                   'typedef std::allocator<int>::pointer' access changed from
'private' to 'public'
                   typedef name changed from std::allocator<int>::pointer to
std::allocator_traits<std::allocator<int> >::pointer at alloc_traits.h:392:1

Note the difference with gcc first:
typedef name changed from std::allocator_traits<std::allocator<int> >::pointer
to std::allocator<int>::pointer at allocator.h:113:1

with clang first:
typedef name changed from std::allocator<int>::pointer to
std::allocator_traits<std::allocator<int> >::pointer at alloc_traits.h:392:1

It is not comparing the same "pointer" class. One is typedef'd inside of
std::allocator<int> and the other is typedef'd inside of
std::allocator_traits<std::allocator<int> >. I admit that this is really hard
to follow manually in GCC's DWARF because of the importing that GCC does but I
think that puzzling it together, this has enough of the DWARF to show that
libabigail is comparing two different "pointer" typedefs from different
template specializations.

 [   410]      structure_type
               name                 (strp)
"allocator_traits<std::allocator<int> >"
               byte_size            (data1) 1
               decl_file            (data1) 4
               decl_line            (data2) 384
               sibling              (ref4) [   50b]
 [   43a]        typedef
                 name                 (strp) "pointer"
                 decl_file            (data1) 4
                 decl_line            (data2) 392
                 type                 (ref4) [  16c6]
...
 [  12e0]    namespace
             name                 (strp) "__gnu_cxx"
             decl_file            (data1) 8
             decl_line            (data2) 2216
             sibling              (ref4) [  15be]
 [  12ec]      namespace
               name                 (strp) "__cxx11"
               decl_file            (data1) 8
               decl_line            (data2) 2218
 [  12f4]      imported_module
               decl_file            (data1) 8
               decl_line            (data2) 2218
               import               (ref4) [  12ec]
 ...
 [  1353]      structure_type
               name                 (strp) "__alloc_traits<std::allocator<int>
>"
               byte_size            (data1) 1
               decl_file            (data1) 16
               decl_line            (data1) 50
               sibling              (ref4) [  1454]
...
 [  1374]        inheritance
                 type                 (ref4) [   410]
                 data_member_location (data1) 0

...
 [  15ef]    base_type
             byte_size            (data1) 4
             encoding             (data1) signed (5)
             name                 (string) "int"
 [  16c6]    pointer_type
             byte_size            (data1) 8
             type                 (ref4) [  15ef]

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

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

[woodard at redhat dot com]

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

--- Comment #10 from Ben Woodard <woodard at redhat dot com> ---
Moving to a slightly bigger test case that doesn't resolve to harmless.
Using --no-unreferenced-symbols reduces some of the noise.

dodji@adjoa:gcc-llvm$ ../../build/tools/abidiff test3-gcc.o test3-clang.o
Functions changes summary: 0 Removed, 0 Changed, 0 Added function
Variables changes summary: 0 Removed, 1 Changed, 0 Added variable
Function symbols changes summary: 11 Removed, 1 Added function symbols not
referenced by debug info
Variable symbols changes summary: 0 Removed, 0 Added variable symbol not
referenced by debug info

1 Changed variable:

  [C]'std::vector<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > > var' was changed to
'std::vector<std::__cxx11::basic_string<char>,
std::allocator<std::__cxx11::basic_string<char> > > var' at test3.C:4:1:
    type of variable changed:
     type name changed from 'std::vector<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >' to 'std::vector<std::__cxx11::basic_string<char>,
std::allocator<std::__cxx11::basic_string<char> > >'
     type size hasn't changed

     1 base class deletion:
       struct std::_Vector_base<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > > at stl_vector.h:74:1
     1 base class insertion:
       struct std::_Vector_base<std::__cxx11::basic_string<char>,
std::allocator<std::__cxx11::basic_string<char> > > at stl_vector.h:74:1


11 Removed function symbols not referenced by debug info:

 
_ZN9__gnu_cxx13new_allocatorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEC1Ev
 
_ZN9__gnu_cxx13new_allocatorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEED1Ev
  _ZNSaINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEC1Ev
  _ZNSaINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEED1Ev
 
_ZNSt12_Vector_baseINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE12_Vector_implC1Ev
 
_ZNSt12_Vector_baseINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE12_Vector_implD1Ev
 
_ZNSt12_Vector_baseINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EEC1Ev
 
_ZNSt12_Vector_baseINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EED1Ev
 
_ZNSt16allocator_traitsISaINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEE10deallocateERS6_PS5_m
  _ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EEC1Ev
  _ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EED1Ev

1 Added function symbol not referenced by debug info:

 
_ZN9__gnu_cxx14__alloc_traitsISaINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEE10deallocateERS7_PS6_m

dodji@adjoa:gcc-llvm$

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

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

[woodard at redhat dot com]

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

--- Comment #6 from Ben Woodard <woodard at redhat dot com> ---
It is getting confused between:

      typedef typename __gnu_cxx::__alloc_traits<_Tp_alloc_type>::pointer
        pointer;

and

      typedef typename _Base::pointer                   pointer;

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

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

[woodard at redhat dot com]

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

--- Comment #7 from Ben Woodard <woodard at redhat dot com> ---
Created attachment 10319
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10319&action=edit
closer to minimal test case

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

[Bug default/21843] libabigail getting confused or possibly bad dwarf

[woodard at redhat dot com]

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

--- Comment #1 from Ben Woodard <woodard at redhat dot com> ---
Created attachment 10288
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10288&action=edit
gcc object

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

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

[woodard at redhat dot com]

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.

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

[woodard at redhat dot com]

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

Ben Woodard <woodard at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #10287|0                           |1
        is obsolete|                            |
  Attachment #10288|0                           |1
        is obsolete|                            |

--- Comment #8 from Ben Woodard <woodard at redhat dot com> ---
Created attachment 10320
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10320&action=edit
gcc object for test3

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

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

[dodji at redhat dot com]

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

dodji at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #4 from dodji at redhat dot com ---
> 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:
>                  underlying type 'typedef
> std::allocator_traits<std::allocator<int> >::pointer' at allocator.h:113:1
> changed:

[...]
           typedef name changed from
> std::allocator_traits<std::allocator<int> >::pointer to
> std::allocator<int>::pointer at allocator.h:113:1
> 

[...]

> 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'. 
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<std::allocator<int> >::pointer is 
is represented by this DWARF:

[   8f0]        typedef
                 type                 (ref4) [   793]
                 name                 (strp) "pointer"

So the underlying type of  __gnu_cxx::__alloc_traits<std::allocator<int>
>::pointer is the type represented by the DIE 0x793.  And that DIE 0x793 is
actually std::allocator<int>::pointer, as we can see here at:

 [   74c]      class_type
               name                 (strp) "allocator<int>"
               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<std::allocator<int>
>::pointer is is represented by this DWARF:

 [  1353]      structure_type
               name                 (strp) "__alloc_traits<std::allocator<int>
>"
               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<std::allocator<int> >"
               byte_size            (data1) 1
               decl_file            (data1) 4
               decl_line            (data2) 384
               sibling              (ref4) [   50b]
[...]
 [   43a]        typedef
                 name                 (strp) "pointer"
                 decl_file            (data1) 4  
                 decl_line            (data2) 392
                 type                 (ref4) [  16c6]

So in GCC, the underlying type of the typedef
__gnu_cxx::__alloc_traits<std::allocator<int> >::pointer is
"allocator_traits<std::allocator<int> >::pointer".

Note the difference in *typedef name* with clang.  With clang, the underlying
type of __gnu_cxx::__alloc_traits<std::allocator<int> >::pointer is
std::allocator<int>::pointer.

So libabigail is saying that "allocator_traits<std::allocator<int> >::pointer"
is a different typedef *name*, compared to "std::allocator<int>::pointer".

What it's failing to see is that both typedefs end up being just "int".

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

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

[woodard at redhat dot com]

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

--- Comment #9 from Ben Woodard <woodard at redhat dot com> ---
Created attachment 10321
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10321&action=edit
clang object for test3

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

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

[woodard at redhat dot com]

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

Ben Woodard <woodard at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|libabigail getting confused |libabigail not correctly
                   |or possibly bad dwarf       |keeping track of nested
                   |                            |scopes for typedefs

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

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

[woodard at redhat dot com]

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

Ben Woodard <woodard at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #11 from Ben Woodard <woodard at redhat dot com> ---
This got fixed in the compilers and in libabigail.

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