From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) by sourceware.org (Postfix) with ESMTPS id 176083858C50; Sun, 1 Jan 2023 17:50:27 +0000 (GMT) Received: (Authenticated sender: dodji@seketeli.org) by mail.gandi.net (Postfix) with ESMTPSA id 8789D20002; Sun, 1 Jan 2023 17:50:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seketeli.org; s=gm1; t=1672595425; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nKvC1PrzYPO6ajab8oLk2gdE2sQAaptMVsvOpd+j+ww=; b=XDl3NpLWoosqHN4ep/yfRT8bgtDxFditY6izG6IkzGWgroJWbC/jPiaEbEIN3/n3SU9EwU dfGel433Jdmq30MaRtfzPHYliArfKMsxncehp1KKqYyRA97J54lsbrNYlZO4FTEoFqx+cR h56hsJjXiUBj8eKwq0IYygTC6BchX0Z7BwjU4kO/lnHapjRZLLCWYu5CulLdj8bzkdUyd1 cUKjW/r6qrBlzOoJKL2j2iD5xaUGhwaYBfgl+XoidN/eBCic3FW2HXYrZZdd0B7xSROGyC DsnKKq+eOFpYHjddEiUWD2oxJWiDZ52ik7At7xZTrAsuGAU1TcnYiGp0Be9nrw== Received: by localhost (Postfix, from userid 1000) id C2ABC581C59; Sun, 1 Jan 2023 18:50:24 +0100 (CET) From: Dodji Seketeli To: "guillermo.e.martinez at oracle dot com via Libabigail" Cc: "guillermo.e.martinez at oracle dot com" Subject: Re: [Bug default/29811] extern array declaration following by its definition reports different sizes in DWARF vs CTF Organization: Me, myself and I References: X-Operating-System: Fedora 38 X-URL: http://www.seketeli.net/~dodji Date: Sun, 01 Jan 2023 18:50:24 +0100 In-Reply-To: (guillermo e. martinez at oracle dot com via Libabigail's message of "Sat, 24 Dec 2022 15:39:23 +0000") Message-ID: <878rimm9en.fsf@seketeli.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > 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 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