From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AFC27385842C; Sun, 1 Jan 2023 17:50:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AFC27385842C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1672595433; bh=vB6hoo/mSKFlloMFC+GWLFKEoxVHfHcfrb8Ha2+d5R4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=udQe0K4+aXgHZ5D9huihqMS1iiaDCKCfjJ960uN4D50wfryoP4KdGZnwrshlSb8O6 1+B381B0Ez3lO4keUH9YMJrDfeQy6kKEHM6coJn9X+UORks9FnTtB3eRCCjU9xiQge MYb+DUeVp5PRtKYLKzig4AOrVdRyRgAZs24ahwKg= 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: Sun, 01 Jan 2023 17:50:30 +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: 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: 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 #5 from dodji at seketeli dot org --- > hmmm sorry for my ignorance, but is_basic_table is an array of unknown si= ze? > As far as I know 'extern' reserved word is telling to compiler that symbo= l 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 [] =3D {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 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=3Dlibabigail.git;a=3Dcommit;h=3D4545e9a23a50d= 5d27182ea56b70b9d5d111e571f 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 C= TF > >> front-end? > >>=20 > > > > 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= =20=20=20=20=20=20=20 > > Variables changes summary: 0 Removed, 1 Changed, 0 Added variable= =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 > > > > [C] 'unsigned int is_basic_table[1]' was changed to 'unsigned i= nt > > 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 > > 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 > > type name changed from 'unsigned int[1]' to 'unsigned int[]= '=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 > > 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 unkno= wn, > its symbol size is known and hasn't changed. Thus, this is not an ABI > change. >=20 > This is on me. This one should be fixed by commit https://sourceware.org/git/?p=3Dlibabigail.git;a=3Dcommit;h=3De02d3b85e321a= 873f3a0a4b788cc93e53e14a5bb in the master branch of the git repository. Thanks! --=20 You are receiving this mail because: You are on the CC list for the bug.=