From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 65F5D3857B8E; Wed, 21 Dec 2022 16:02:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 65F5D3857B8E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1671638571; bh=xMjgsdz0RyGVaPPfflKOw/FC5fF6HEG96TC4TfTSXfM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VS10Lpq/4FsD73uw0ErzQTdh62rz9QSD1yvunE5yov0xO/TBDk7IAiiVPf9t7dkjC cU3wrzoDDp0/ID8wuDqwLdHWUl1d0dErLknQavGhmeHTJL2pSn/tJYemd9tRPrZCb+ oZN/G70vLy4LdqD1hp9mLyODTjvT4+4qEs+HqPoM= 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: Wed, 21 Dec 2022 16:02:49 +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: UNCONFIRMED 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 #1 from dodji at seketeli dot org --- Hello, > The following C code generates a infinite subrange length using DWARF > front-end. > > extern unsigned int is_basic_table[]; > > unsigned int is_basic_table [] =3D > { > 0, > }; So, the declaration unsigned int is_basic_table[] is a declaration of an array of "unknown" size. So, the type of is_basic_table is "array of unsigned int, of unknown size". In this particular case, is_basic_table is initialized with an array of one element of type unsigned int. So, let's look at what DWARF description of this looks like: $ cat test.c extern unsigned int is_basic_table[]; unsigned int is_basic_table [] =3D { 0, }; $=20 $ gcc -g -c test.c $ $ eu-readelf --debug-dump=3Dinfo test.o | cat -n 1=20=20 2 DWARF section [ 4] '.debug_info' at offset 0x40: 3 [Offset] 4 Compilation unit at offset 0: 5 Version: 5, Abbreviation section offset: 0, Address size: 8, Offset size: 4 6 Unit type: compile (1) 7 [ c] compile_unit abbrev: 3 8 producer (strp) "GNU C17 11.3.1 20221121 (Red Hat 11.3.1-4) -mtune=3Dgeneric -march=3Dx86-64-v2 -g" 9 language (data1) C11 (29) 10 name (line_strp) "test.c" 11 comp_dir (line_strp) "/home/dodji/git/libabigail/fixes/prtests/PR29811" 12 stmt_list (sec_offset) 0 13 [ 1e] array_type abbrev: 1 14 type (ref4) [ 29] 15 sibling (ref4) [ 29] 16 [ 27] subrange_type abbrev: 4 17 [ 29] base_type abbrev: 2 18 byte_size (data1) 4 19 encoding (implicit_const) unsigned (7) 20 name (strp) "unsigned int" 21 [ 2f] variable abbrev: 5 22 name (strp) "is_basic_table" 23 decl_file (data1) test.c (1) 24 decl_line (data1) 1 25 decl_column (data1) 21 26 type (ref4) [ 1e] 27 external (flag_present) yes 28 declaration (flag_present) yes 29 [ 3b] array_type abbrev: 1 30 type (ref4) [ 29] 31 sibling (ref4) [ 4b] 32 [ 44] subrange_type abbrev: 6 33 type (ref4) [ 4b] 34 upper_bound (data1) 0 35 [ 4b] base_type abbrev: 2 36 byte_size (data1) 8 37 encoding (implicit_const) unsigned (7) 38 name (strp) "long unsigned int" 39 [ 51] variable abbrev: 7 40 specification (ref4) [ 2f] 41 decl_line (data1) 3 42 decl_column (data1) 14 43 type (ref4) [ 3b] 44 location (exprloc)=20 45 [ 0] addr .bss+0 $=20 >From line 21 to line 26, we see that the Debug Information Entry (a.k.a DIE) that describes the variable is_basic_table is the following: 21 [ 2f] variable abbrev: 5 22 name (strp) "is_basic_table" 23 decl_file (data1) test.c (1) 24 decl_line (data1) 1 25 decl_column (data1) 21 26 type (ref4) [ 1e] At line 26, we see that the the value of "type" attribute of the variable DIE is 0x1e. Which means that the DIE describing the type of the is_basic_table variable is the DIE which offset is 0x1e. That DIE which offset 0x1e is at line 13: 13 [ 1e] array_type abbrev: 1 14 type (ref4) [ 29] 15 sibling (ref4) [ 29] 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". That is what libabigail expresses by the keyword "infinite". I probably could have chosen a better keyword here ;-) Anyway, "infinite" really means "unknown" here. But then, you are right in saying that: > The symbol size showed by objdump: > 0000000000000000 g O .bss 0000000000000004 is_basic_table That is the symbol view of things. Note the type description as written in the source code. In other words, the size "4" there is the size of the ELF symbol is_basic_table, which is the ELF symbol for the is_basic_table C variable. The ELF symbol named "is_basic_table" is described by libabigail as can been seen by doing: $ /home/dodji/git/libabigail/fixes/build/tools/abidw test.o 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 $ At line 3, we can see: So we see that the symbol is_basic_table has a size of 4. So I think that today, all the information is kept in the model: what the source code said, and what the actual symbol looks like. Let's look at what the comparison & reporting engine are saying when comparing the IRs of DWARF against CTF: > Thus, abidiff abi-ctf.xml abi-dwarf.xml, reports: > > 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=20=20 > > [C] 'unsigned int is_basic_table[]' was changed at test-extern-array.c:= 3:1:=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=20=20 > array element type 'unsigned int' 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 > type size hasn't changed > type alignment changed from 32 to 0=20=20=20=20=20=20=20=20=20=20= =20=20=20=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 size hasn't changed You can see the report says that the type hasn't changed. > type alignment changed from 32 to 0 What has changed is the alignment. the DWARF front-end considers the alignment to be zero for arrays. This is because there is no specific alignment information for that type so we set it to zero. Do you know what happens if you set the alignment to zero in the CTF front-end? Cheers, --=20 You are receiving this mail because: You are on the CC list for the bug.=