From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
	id DA97538582A3; Sat, 24 Dec 2022 15:39:41 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DA97538582A3
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1671896381;
	bh=JJ0JaSIy//xaHkOfWy8ZxELecMN2n9agqoC4rrQSFME=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=VaybFdSE9cYmqKJ27oL7fGNOhwM4zkCQCal+ttln8yzLS0PgoDDiXqkVjW0elU/hy
	 OH6at9lkxD+t66IZRnLRv/V3StAc5+omYTceaklX7SCRm0kniTuntutHpkxdpFR095
	 EfPi8kDzvjXgI9wLa7l7zyMYSEy6XJzm8iCd2mmI=
From: "guillermo.e.martinez at oracle dot com"
 <sourceware-bugzilla@sourceware.org>
To: libabigail@sourceware.org
Subject: [Bug default/29811] extern array declaration following by its
 definition reports different sizes in DWARF vs CTF
Date: Sat, 24 Dec 2022 15:39:23 +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: guillermo.e.martinez at oracle 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-29811-9487-FvyTDbPkST@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-29811-9487@http.sourceware.org/bugzilla/>
References: <bug-29811-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
List-Id: <libabigail.sourceware.org>

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

--- Comment #4 from Guillermo E. Martinez <guillermo.e.martinez at oracle d=
ot com> ---
(In reply to dodji from comment #3)
> "guillermo.e.martinez at oracle dot com via Libabigail"
> <libabigail@sourceware.org> a =C3=A9crit:
>=20
> > Thanks for this great explanation!
>=20
> You are welcome!
>=20
> [...]
>=20
>=20
> >> As you can see there, that DIE has no "size" attribute.  That is in li=
ne
> >> with the type of is_basic_table, as declared in the C source code, whi=
ch
> >> is "Array of unknown size".
> >>=20
> >
> > So, Is it a limitation of DWARF info?
>=20
> I wouldn't say it's a limitation.  Rather, I'd say that it's a feature.
> In that case DWARF keeps the information about the exact type of the
> variable as written in the source code.  That type really is "array of
> unknown size".
>=20
> The actual size taken by the variable in memory can be derived from the
> initializer.  Not from the type definition.  So I think that DWARF is
> correct here.
>=20
> [...]
>=20
> >
> > Right, just that it is limited to _symbol_information not saying much a=
bout of
> > type symbol, it is most evident when we use abidiff changing the array =
size,
> > using CTF and DWARF front-end (e.g I changed the array's elements to tw=
o):
>=20
> If I understand correctly, you changed the size of the array in the
> initializer, right?
>=20

Yes, correct.

> >
> > $ abidiff test-01.o test-02.o
> >
> > Functions changes summary: 0 Removed, 0 Changed, 0 Added function=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20
> >   Variables changes summary: 0 Removed, 1 Changed, 0 Added variable=20=
=20=20=20=20=20=20=20=20=20=20=20=20
> >
> >   1 Changed variable:=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
> >
> >     [C] 'unsigned int is_basic_table[]' was changed at test03.c:1:1:=20=
=20=20=20=20=20=20=20=20=20=20=20
> >       size of symbol changed from 4 to 8=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20
>=20
> I would guess so.  So both variables have the same type (array of
> uninitialized size), but their initializer have different size.  See,
> that information is kept all along.
>=20
> If on the other hand, you say that the type size should be set to 1,
> then we wouldn't know the difference between:
>=20
>     unsigned is_basic_table[] =3D {0};
>=20
> and
>=20
>     unsigned is_basic_table[1];
>=20
> Even if in the end, the ABI ends up being the same, there is a subtle
> difference there that would be lost.  And I think that it's important to
> keep information for users at this point.
>=20
> Is it possible to have that information from CTF?  I mean, is it
> possible to have CTF tell us that is_basic_table is an array of unknown
> size?
>=20

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 t=
hat
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
-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20
  <stdin>:1:14: warning: array =E2=80=98is_basic_table=E2=80=99 assumed to =
have one element=20=20=20=20=20

$ abidw ~/c/test03.o

<abi-corpus version=3D'2.1' path=3D'/home/byby/c/test03.o'
architecture=3D'elf-amd-x86_64'>
    <elf-variable-symbols>
      <elf-symbol name=3D'is_basic_table' size=3D'4' type=3D'object-type'
binding=3D'global-binding' visibility=3D'default-visibility' is-defined=3D'=
yes'/>
    </elf-variable-symbols>
    <abi-instr address-size=3D'64' path=3D'&lt;stdin&gt;'
comp-dir-path=3D'/home/byby/oracle/src/libabigail-new' language=3D'LANG_C11=
'>
      <type-decl name=3D'unsigned int' size-in-bits=3D'32' id=3D'type-id-1'=
/>
      <array-type-def dimensions=3D'1' type-id=3D'type-id-1'
size-in-bits=3D'infinite' id=3D'type-id-2'>
        <subrange length=3D'infinite' id=3D'type-id-3'/>
      </array-type-def>
      <var-decl name=3D'is_basic_table' type-id=3D'type-id-2'
mangled-name=3D'is_basic_table' visibility=3D'default'
filepath=3D'/home/byby/oracle/src/libabigail-new/&lt;stdin&gt;' line=3D'1'
column=3D'1' elf-symbol-id=3D'is_basic_table'/>
    </abi-instr>
</abi-corpus>

$ abidw --ctf ~/c/test03.o=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20

<abi-corpus version=3D'2.1' path=3D'/home/byby/c/test03.o'
architecture=3D'elf-amd-x86_64'>
    <elf-variable-symbols>
      <elf-symbol name=3D'is_basic_table' size=3D'4' type=3D'object-type'
binding=3D'global-binding' visibility=3D'default-visibility' is-defined=3D'=
yes'/>
    </elf-variable-symbols>
    <abi-instr address-size=3D'64' language=3D'LANG_C'>
      <type-decl name=3D'unsigned int' size-in-bits=3D'32' id=3D'type-id-1'=
/>
      <array-type-def dimensions=3D'1' type-id=3D'type-id-1'
size-in-bits=3D'infinite' id=3D'type-id-2'>
        <subrange length=3D'infinite' type-id=3D'type-id-3' id=3D'type-id-4=
'/>
      </array-type-def>
      <var-decl name=3D'is_basic_table' type-id=3D'type-id-2'
mangled-name=3D'is_basic_table' visibility=3D'default'
elf-symbol-id=3D'is_basic_table'/>
      <type-decl name=3D'void' id=3D'type-id-3'/>
    </abi-instr>
</abi-corpus>


> >
> > $ abidiff --ctf test-01.o test-02.o
> >
> > Functions changes summary: 0 Removed, 0 Changed, 0 Added function=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20
> >   Variables changes summary: 0 Removed, 1 Changed, 0 Added variable=20=
=20=20=20=20=20=20=20=20=20=20=20=20
> >
> >   1 Changed variable:=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
> >
> >     [C] 'unsigned int is_basic_table[1]' was changed to 'unsigned int
> > is_basic_table[2]':=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
> >       size of symbol changed from 4 to 8=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20
> >       type of variable changed:=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20
> >         type name changed from 'unsigned int[1]' to 'unsigned int[2]'=
=20=20=20=20=20=20=20=20=20=20=20
> >         array type size changed from 32 to 64=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20
> >         array type subrange 1 changed length from 1 to 2
>=20
> Here, it looks like abidiff is reporting about the difference between:
>=20
> unsigned is_basic_table[1];
>=20
> and
> unsigned is_basic_table[2];
>=20
> The information about the fact that we are actually looking at
>=20
> unsigned is_basic_table[], initialized with two different initializers
> is lost.
>=20
> So, it seems to me that DWARF is more fined grained here.
>=20
> It would be nice to have that same level of finesse from CTF, if
> possible.  Is that possible?
>=20
> [...]
>=20
>=20
> >> Do you know what happens if you set the alignment to zero in the CTF
> >> front-end?
> >>=20
> >
> > Yes, I changed the alignment value in CTF front-end in commit: 8b832a9e=
dfa,
> > 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=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20
> >   Variables changes summary: 0 Removed, 1 Changed, 0 Added variable=20=
=20=20=20=20=20=20=20=20=20=20=20=20
> >
> >   1 Changed variable:=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
> >
> >     [C] 'unsigned int is_basic_table[1]' was changed to 'unsigned int
> > is_basic_table[]' at test03.c:1:1:=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20
> >       type of variable changed:=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20
> >         type name changed from 'unsigned int[1]' to 'unsigned int[]'=20=
=20=20=20=20=20=20=20=20=20=20=20
> >         array type size changed from 32 to infinity=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
> >         array type subrange 1 changed length from 1 to infinity=20=20=20
>=20
> OK, fair enough.
>=20
> 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.
>=20
> This is on me.

Kind regards,
guillermo

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