Re: [Bug default/29811] extern array declaration following by its definition reports different sizes in DWARF vs CTF

[Dodji Seketeli <dodji@seketeli.org>]

> hmmm sorry for my ignorance, but is_basic_table is an array of unknown size?
> As far as I know 'extern' reserved word is telling to compiler that symbol used
> in the current translation unit is _declared_ in another one, and is this that
> we are interested right?
>
> So, the following declaration produces both CTF and DWARF subrange nodes at
> 'infinite':
>
> $ echo 'unsigned int is_basic_table[];' | gcc -g -gctf -c -o ~/c/test03.o -x c

Ahhh, okay, I see.  I think you are right: I made a mistake in interpreting the DWARF
output.

Here, is what I think happening.  There are two DIEs in the DWARF debug
info for the type of is_basic_table.  One is for the array of unknown
type that is present in the declaration:

    extern unsigned int is_basic_table[];.

And one is for the array of one element of type "unsigned int" that is
present in the definition:

    unsigned int is_basic_table [] = {0};

In the DWARF, the first type is described at:

 [    1e]    array_type           abbrev: 1
             type                 (ref4) [    29]
             sibling              (ref4) [    29]
 [    27]      subrange_type        abbrev: 4


However, we see that the type of the definition of the is_basic_table
variable is given by:

 [    51]    variable             abbrev: 7
             specification        (ref4) [    2f]
             decl_line            (data1) 3
             decl_column          (data1) 14
             type                 (ref4) [    3b]
             location             (exprloc)
              [ 0] addr .bss+0 <is_basic_table>

And so that type points to the DIE at offset 0x3b (not the one at offset
0x1e that I showed earlier):

 [    3b]    array_type           abbrev: 1
             type                 (ref4) [    29]
             sibling              (ref4) [    4b]
 [    44]      subrange_type        abbrev: 6
               type                 (ref4) [    4b]
               upper_bound          (data1) 0

You see that the array type at offset 0x3b does have a
DW_TAG_subrange_type with an DW_AT_upper_bound attribute value set to
zero, meaning that the array does have one element, unlike the type DIE
at 0x1e which DW_TAG_subrange_type has no DW_AT_upper_bound attribute
meaning that it's on unknown size.

The problem here is that the DWARF reader links the is_array_type to the
wrong type.  So you are right, this is a problem coming from the DWARF
reader implementation.

I think it should now be fixed by the patch
https://sourceware.org/git/?p=libabigail.git;a=commit;h=4545e9a23a50d5d27182ea56b70b9d5d111e571f
in the master branch of the git repository.

There is also another separate issue, which is the one we talked about
at in a previous comment of the problem report, namely:

    > >> Do you know what happens if you set the alignment to zero in the CTF
    > >> front-end?
    > >> 
    > >
    > > Yes, I changed the alignment value in CTF front-end in commit: 8b832a9edfa,
    > > and I tested with latest commit until now: 4cf2ef8f9.
    > >
    > > $ abidiff abi-ctf.xml abi-dwarf.xml
    > >
    > > Functions changes summary: 0 Removed, 0 Changed, 0 Added function               
    > >   Variables changes summary: 0 Removed, 1 Changed, 0 Added variable             
    > >
    > >   1 Changed variable:                                                           
    > >
    > >     [C] 'unsigned int is_basic_table[1]' was changed to 'unsigned int
    > > is_basic_table[]' at test03.c:1:1:                                              
    > >       type of variable changed:                                                 
    > >         type name changed from 'unsigned int[1]' to 'unsigned int[]'            
    > >         array type size changed from 32 to infinity                             
    > >         array type subrange 1 changed length from 1 to infinity   
    > 
    > OK, fair enough.
    > 
    > I think that here, we should teach libabigail's comparison engine to
    > take into account the fact that although the array type size is unknown,
    > its symbol size is known and hasn't changed.  Thus, this is not an ABI
    > change.
    > 
    > This is on me.

This one should be fixed by commit
https://sourceware.org/git/?p=libabigail.git;a=commit;h=e02d3b85e321a873f3a0a4b788cc93e53e14a5bb
in the master branch of the git repository.

Thanks!

-- 
		Dodji