From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 948EB3858284; Fri, 23 Dec 2022 09:19:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 948EB3858284 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1671787180; bh=C8ovUn3FUBuejDOZJkQ46oUOGSKjcIjNjqQAowkRsPY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Ado63clxj6HOm2LzUabn6INo7Fn0ev86nt5oTeorp4z6zyokzPy+JAauZd7iW8hG9 aJf45fKX8zXvTYJ+OxCnmcjquhn2tXCavfqqhrlfYdD7MqgKWejq2zVKnQkoYHbpx5 RYaBj6jupBfMfzZqIwzeACp2LBYRqN5LPbrJI2Tc= From: "dodji at seketeli dot org" To: libabigail@sourceware.org Subject: [Bug default/29811] extern array declaration following by its definition reports different sizes in DWARF vs CTF Date: Fri, 23 Dec 2022 09:19:37 +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 seketeli dot org X-Bugzilla-Status: WAITING 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: 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 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29811 --- Comment #3 from dodji at seketeli dot org --- "guillermo.e.martinez at oracle dot com via Libabigail" a =C3=A9crit: > Thanks for this great explanation! You are welcome! [...] >> As you can see there, that DIE has no "size" attribute. That is in line >> with the type of is_basic_table, as declared in the C source code, which >> is "Array of unknown size". >>=20 > > So, Is it a limitation of DWARF info? 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". 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. [...] > > Right, just that it is limited to _symbol_information not saying much abo= ut of > type symbol, it is most evident when we use abidiff changing the array si= ze, > using CTF and DWARF front-end (e.g I changed the array's elements to two): If I understand correctly, you changed the size of the array in the initializer, right? > > $ 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 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. If on the other hand, you say that the type size should be set to 1, then we wouldn't know the difference between: unsigned is_basic_table[] =3D {0}; and unsigned is_basic_table[1]; 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. 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? > > $ 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 Here, it looks like abidiff is reporting about the difference between: unsigned is_basic_table[1]; and unsigned is_basic_table[2]; The information about the fact that we are actually looking at unsigned is_basic_table[], initialized with two different initializers is lost. So, it seems to me that DWARF is more fined grained here. It would be nice to have that same level of finesse from CTF, if possible. Is that possible? [...] >> 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: 8b832a9edf= a, > 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 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. --=20 You are receiving this mail because: You are on the CC list for the bug.=