* Re: [Bug default/29811] New: extern array declaration following by its definition reports different sizes in DWARF vs CTF
2022-11-21 4:09 [Bug default/29811] New: extern array declaration following by its definition reports different sizes in DWARF vs CTF guillermo.e.martinez at oracle dot com
@ 2022-12-21 16:02 ` Dodji Seketeli
2022-12-21 16:02 ` [Bug default/29811] " dodji at seketeli dot org
` (7 subsequent siblings)
8 siblings, 0 replies; 12+ messages in thread
From: Dodji Seketeli @ 2022-12-21 16:02 UTC (permalink / raw)
To: guillermo.e.martinez at oracle dot com via Libabigail
Cc: guillermo.e.martinez at oracle dot com
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 [] =
> {
> 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 [] =
{
0,
};
$
$ gcc -g -c test.c
$
$ eu-readelf --debug-dump=info test.o | cat -n
1
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=generic -march=x86-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)
45 [ 0] addr .bss+0 <is_basic_table>
$
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 <abi-corpus version='2.1' path='test.o' architecture='elf-amd-x86_64'>
2 <elf-variable-symbols>
3 <elf-symbol name='is_basic_table' size='4' type='object-type' binding='global-binding' visibility='default-visibility' is-defined='yes'/>
4 </elf-variable-symbols>
5 <abi-instr address-size='64' path='test.c' comp-dir-path='/home/dodji/git/libabigail/fixes/prtests/PR29811' language='LANG_C11'>
6 <type-decl name='unsigned int' size-in-bits='32' id='type-id-1'/>
7 <array-type-def dimensions='1' type-id='type-id-1' size-in-bits='32' id='type-id-2'>
8 <subrange length='1' type-id='type-id-3' id='type-id-4'/>
9 </array-type-def>
10 <array-type-def dimensions='1' type-id='type-id-1' size-in-bits='infinite' id='type-id-5'>
11 <subrange length='infinite' id='type-id-6'/>
12 </array-type-def>
13 <type-decl name='unsigned long int' size-in-bits='64' id='type-id-3'/>
14 <var-decl name='is_basic_table' type-id='type-id-5' mangled-name='is_basic_table' visibility='default' filepath='/home/dodji/git/libabigail/fixes/prtests/PR29811/test.c' line='1' column='1' elf-symbol-id='is_basic_table'/>
15 </abi-instr>
16 </abi-corpus>
$
At line 3, we can see:
<elf-symbol name='is_basic_table' size='4' type='object-type' binding='global-binding' visibility='default-visibility' is-defined='yes'/>
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:
>
> [C] 'unsigned int is_basic_table[]' was changed at test-extern-array.c:3:1:
> type of variable changed:
> array element type 'unsigned int' changed:
> type size hasn't changed
> type alignment changed from 32 to 0
> 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,
--
Dodji
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug default/29811] extern array declaration following by its definition reports different sizes in DWARF vs CTF
2022-11-21 4:09 [Bug default/29811] New: extern array declaration following by its definition reports different sizes in DWARF vs CTF guillermo.e.martinez at oracle dot com
2022-12-21 16:02 ` Dodji Seketeli
@ 2022-12-21 16:02 ` dodji at seketeli dot org
2022-12-22 10:17 ` dodji at redhat dot com
` (6 subsequent siblings)
8 siblings, 0 replies; 12+ messages in thread
From: dodji at seketeli dot org @ 2022-12-21 16:02 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=29811
--- 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 [] =
> {
> 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 [] =
{
0,
};
$
$ gcc -g -c test.c
$
$ eu-readelf --debug-dump=info test.o | cat -n
1
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=generic -march=x86-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)
45 [ 0] addr .bss+0 <is_basic_table>
$
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 <abi-corpus version='2.1' path='test.o'
architecture='elf-amd-x86_64'>
2 <elf-variable-symbols>
3 <elf-symbol name='is_basic_table' size='4'
type='object-type' binding='global-binding' visibility='default-visibility'
is-defined='yes'/>
4 </elf-variable-symbols>
5 <abi-instr address-size='64' path='test.c'
comp-dir-path='/home/dodji/git/libabigail/fixes/prtests/PR29811'
language='LANG_C11'>
6 <type-decl name='unsigned int' size-in-bits='32'
id='type-id-1'/>
7 <array-type-def dimensions='1' type-id='type-id-1'
size-in-bits='32' id='type-id-2'>
8 <subrange length='1' type-id='type-id-3' id='type-id-4'/>
9 </array-type-def>
10 <array-type-def dimensions='1' type-id='type-id-1'
size-in-bits='infinite' id='type-id-5'>
11 <subrange length='infinite' id='type-id-6'/>
12 </array-type-def>
13 <type-decl name='unsigned long int' size-in-bits='64'
id='type-id-3'/>
14 <var-decl name='is_basic_table' type-id='type-id-5'
mangled-name='is_basic_table' visibility='default'
filepath='/home/dodji/git/libabigail/fixes/prtests/PR29811/test.c' line='1'
column='1' elf-symbol-id='is_basic_table'/>
15 </abi-instr>
16 </abi-corpus>
$
At line 3, we can see:
<elf-symbol name='is_basic_table' size='4' type='object-type'
binding='global-binding' visibility='default-visibility' is-defined='yes'/>
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:
>
> [C] 'unsigned int is_basic_table[]' was changed at test-extern-array.c:3:1:
> type of variable changed:
> array element type 'unsigned int' changed:
> type size hasn't changed
> type alignment changed from 32 to 0
> 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,
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug default/29811] extern array declaration following by its definition reports different sizes in DWARF vs CTF
2022-11-21 4:09 [Bug default/29811] New: extern array declaration following by its definition reports different sizes in DWARF vs CTF guillermo.e.martinez at oracle dot com
2022-12-21 16:02 ` Dodji Seketeli
2022-12-21 16:02 ` [Bug default/29811] " dodji at seketeli dot org
@ 2022-12-22 10:17 ` dodji at redhat dot com
2022-12-22 15:27 ` guillermo.e.martinez at oracle dot com
` (5 subsequent siblings)
8 siblings, 0 replies; 12+ messages in thread
From: dodji at redhat dot com @ 2022-12-22 10:17 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=29811
dodji at redhat dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2022-12-22
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug default/29811] extern array declaration following by its definition reports different sizes in DWARF vs CTF
2022-11-21 4:09 [Bug default/29811] New: extern array declaration following by its definition reports different sizes in DWARF vs CTF guillermo.e.martinez at oracle dot com
` (2 preceding siblings ...)
2022-12-22 10:17 ` dodji at redhat dot com
@ 2022-12-22 15:27 ` guillermo.e.martinez at oracle dot com
2022-12-23 9:19 ` Dodji Seketeli
2022-12-23 9:19 ` dodji at seketeli dot org
` (4 subsequent siblings)
8 siblings, 1 reply; 12+ messages in thread
From: guillermo.e.martinez at oracle dot com @ 2022-12-22 15:27 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=29811
--- Comment #2 from Guillermo E. Martinez <guillermo.e.martinez at oracle dot com> ---
Hello Dodji,
Thanks for this great explanation!
(In reply to Guillermo E. Martinez from comment #0)
> The following C code generates a infinite subrange length using DWARF
> front-end.
>
> extern unsigned int is_basic_table[];
>
> unsigned int is_basic_table [] =
> {
> 0,
> };
>
> <array-type-def dimensions='1' type-id='type-id-1' size-in-bits='infinite'
> alignment-in-bits='32' id='type-id-2'>
> <subrange length='infinite' type-id='type-id-3' id='type-id-4'/>
> </array-type-def>
>
>
> Using CTF:
>
> <array-type-def dimensions='1' type-id='type-id-1' size-in-bits='32'
> id='type-id-2'>
> <subrange length='1' type-id='type-id-3' id='type-id-4'/>
> </array-type-def>
>
> Thus, abidiff abi-ctf.xml abi-dwarf.xml, reports:
>
> 1 Changed variable:
>
>
>
> [C] 'unsigned int is_basic_table[]' was changed at
> test-extern-array.c:3:1:
>
> type of variable changed:
>
> array element type 'unsigned int' changed:
>
> type size hasn't changed
>
> type alignment changed from 32 to 0
>
> type size hasn't changed
>
> type alignment changed from 32 to 0
>
> The symbol size showed by objdump:
>
> 0000000000000000 g O .bss 0000000000000004 is_basic_table
>
> Thanks.
(In reply to dodji from comment #1)
> 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 [] =
> > {
> > 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 [] =
> {
> 0,
> };
> $
> $ gcc -g -c test.c
> $
> $ eu-readelf --debug-dump=info test.o | cat -n
> 1
> 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=generic -march=x86-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)
> 45 [ 0] addr .bss+0 <is_basic_table>
> $
>
> 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".
>
So, Is it a limitation of DWARF info?
> 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.
>
Right, just that it is limited to _symbol_information not saying much about 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 two):
$ abidiff test-01.o test-02.o
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[]' was changed at test03.c:1:1:
size of symbol changed from 4 to 8
$ abidiff --ctf test-01.o test-02.o
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[2]':
size of symbol changed from 4 to 8
type of variable changed:
type name changed from 'unsigned int[1]' to 'unsigned int[2]'
array type size changed from 32 to 64
array type subrange 1 changed length from 1 to 2
> 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 <abi-corpus version='2.1' path='test.o'
> architecture='elf-amd-x86_64'>
> 2 <elf-variable-symbols>
> 3 <elf-symbol name='is_basic_table' size='4' type='object-type'
> binding='global-binding' visibility='default-visibility' is-defined='yes'/>
> 4 </elf-variable-symbols>
> 5 <abi-instr address-size='64' path='test.c'
> comp-dir-path='/home/dodji/git/libabigail/fixes/prtests/PR29811'
> language='LANG_C11'>
> 6 <type-decl name='unsigned int' size-in-bits='32'
> id='type-id-1'/>
> 7 <array-type-def dimensions='1' type-id='type-id-1'
> size-in-bits='32' id='type-id-2'>
> 8 <subrange length='1' type-id='type-id-3' id='type-id-4'/>
> 9 </array-type-def>
> 10 <array-type-def dimensions='1' type-id='type-id-1'
> size-in-bits='infinite' id='type-id-5'>
> 11 <subrange length='infinite' id='type-id-6'/>
> 12 </array-type-def>
> 13 <type-decl name='unsigned long int' size-in-bits='64'
> id='type-id-3'/>
> 14 <var-decl name='is_basic_table' type-id='type-id-5'
> mangled-name='is_basic_table' visibility='default'
> filepath='/home/dodji/git/libabigail/fixes/prtests/PR29811/test.c' line='1'
> column='1' elf-symbol-id='is_basic_table'/>
> 15 </abi-instr>
> 16 </abi-corpus>
> $
>
> At line 3, we can see:
>
> <elf-symbol name='is_basic_table' size='4' type='object-type'
> binding='global-binding' visibility='default-visibility' is-defined='yes'/>
>
> 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:
> >
> > [C] 'unsigned int is_basic_table[]' was changed at test-extern-array.c:3:1:
> > type of variable changed:
> > array element type 'unsigned int' changed:
> > type size hasn't changed
> > type alignment changed from 32 to 0
> > 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?
>
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
> Cheers,
Kind regards,
guillermo
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [Bug default/29811] extern array declaration following by its definition reports different sizes in DWARF vs CTF
2022-12-22 15:27 ` guillermo.e.martinez at oracle dot com
@ 2022-12-23 9:19 ` Dodji Seketeli
0 siblings, 0 replies; 12+ messages in thread
From: Dodji Seketeli @ 2022-12-23 9:19 UTC (permalink / raw)
To: guillermo.e.martinez at oracle dot com via Libabigail
Cc: guillermo.e.martinez at oracle dot com
"guillermo.e.martinez at oracle dot com via Libabigail"
<libabigail@sourceware.org> a écrit:
> 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".
>>
>
> 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 about 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 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
> Variables changes summary: 0 Removed, 1 Changed, 0 Added variable
>
> 1 Changed variable:
>
> [C] 'unsigned int is_basic_table[]' was changed at test03.c:1:1:
> size of symbol changed from 4 to 8
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[] = {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
> 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[2]':
> size of symbol changed from 4 to 8
> type of variable changed:
> type name changed from 'unsigned int[1]' to 'unsigned int[2]'
> array type size changed from 32 to 64
> 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?
>>
>
> 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.
--
Dodji
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug default/29811] extern array declaration following by its definition reports different sizes in DWARF vs CTF
2022-11-21 4:09 [Bug default/29811] New: extern array declaration following by its definition reports different sizes in DWARF vs CTF guillermo.e.martinez at oracle dot com
` (3 preceding siblings ...)
2022-12-22 15:27 ` guillermo.e.martinez at oracle dot com
@ 2022-12-23 9:19 ` dodji at seketeli dot org
2022-12-23 9:20 ` dodji at redhat dot com
` (3 subsequent siblings)
8 siblings, 0 replies; 12+ messages in thread
From: dodji at seketeli dot org @ 2022-12-23 9:19 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=29811
--- Comment #3 from dodji at seketeli dot org ---
"guillermo.e.martinez at oracle dot com via Libabigail"
<libabigail@sourceware.org> a écrit:
> 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".
>>
>
> 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 about 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 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
> Variables changes summary: 0 Removed, 1 Changed, 0 Added variable
>
> 1 Changed variable:
>
> [C] 'unsigned int is_basic_table[]' was changed at test03.c:1:1:
> size of symbol changed from 4 to 8
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[] = {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
> 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[2]':
> size of symbol changed from 4 to 8
> type of variable changed:
> type name changed from 'unsigned int[1]' to 'unsigned int[2]'
> array type size changed from 32 to 64
> 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?
>>
>
> 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.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug default/29811] extern array declaration following by its definition reports different sizes in DWARF vs CTF
2022-11-21 4:09 [Bug default/29811] New: extern array declaration following by its definition reports different sizes in DWARF vs CTF guillermo.e.martinez at oracle dot com
` (4 preceding siblings ...)
2022-12-23 9:19 ` dodji at seketeli dot org
@ 2022-12-23 9:20 ` dodji at redhat dot com
2022-12-24 15:39 ` guillermo.e.martinez at oracle dot com
` (2 subsequent siblings)
8 siblings, 0 replies; 12+ messages in thread
From: dodji at redhat dot com @ 2022-12-23 9:20 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=29811
dodji at redhat dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |ASSIGNED
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug default/29811] extern array declaration following by its definition reports different sizes in DWARF vs CTF
2022-11-21 4:09 [Bug default/29811] New: extern array declaration following by its definition reports different sizes in DWARF vs CTF guillermo.e.martinez at oracle dot com
` (5 preceding siblings ...)
2022-12-23 9:20 ` dodji at redhat dot com
@ 2022-12-24 15:39 ` guillermo.e.martinez at oracle dot com
2023-01-01 17:50 ` Dodji Seketeli
2023-01-01 17:50 ` dodji at seketeli dot org
2023-01-01 17:57 ` dodji at redhat dot com
8 siblings, 1 reply; 12+ messages in thread
From: guillermo.e.martinez at oracle dot com @ 2022-12-24 15:39 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=29811
--- Comment #4 from Guillermo E. Martinez <guillermo.e.martinez at oracle dot com> ---
(In reply to dodji from comment #3)
> "guillermo.e.martinez at oracle dot com via Libabigail"
> <libabigail@sourceware.org> a écrit:
>
> > 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".
> >>
> >
> > 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 about 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 two):
>
> If I understand correctly, you changed the size of the array in the
> initializer, right?
>
Yes, correct.
> >
> > $ abidiff test-01.o test-02.o
> >
> > 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[]' was changed at test03.c:1:1:
> > size of symbol changed from 4 to 8
>
> 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[] = {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?
>
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
-
<stdin>:1:14: warning: array ‘is_basic_table’ assumed to have one element
$ abidw ~/c/test03.o
<abi-corpus version='2.1' path='/home/byby/c/test03.o'
architecture='elf-amd-x86_64'>
<elf-variable-symbols>
<elf-symbol name='is_basic_table' size='4' type='object-type'
binding='global-binding' visibility='default-visibility' is-defined='yes'/>
</elf-variable-symbols>
<abi-instr address-size='64' path='<stdin>'
comp-dir-path='/home/byby/oracle/src/libabigail-new' language='LANG_C11'>
<type-decl name='unsigned int' size-in-bits='32' id='type-id-1'/>
<array-type-def dimensions='1' type-id='type-id-1'
size-in-bits='infinite' id='type-id-2'>
<subrange length='infinite' id='type-id-3'/>
</array-type-def>
<var-decl name='is_basic_table' type-id='type-id-2'
mangled-name='is_basic_table' visibility='default'
filepath='/home/byby/oracle/src/libabigail-new/<stdin>' line='1'
column='1' elf-symbol-id='is_basic_table'/>
</abi-instr>
</abi-corpus>
$ abidw --ctf ~/c/test03.o
<abi-corpus version='2.1' path='/home/byby/c/test03.o'
architecture='elf-amd-x86_64'>
<elf-variable-symbols>
<elf-symbol name='is_basic_table' size='4' type='object-type'
binding='global-binding' visibility='default-visibility' is-defined='yes'/>
</elf-variable-symbols>
<abi-instr address-size='64' language='LANG_C'>
<type-decl name='unsigned int' size-in-bits='32' id='type-id-1'/>
<array-type-def dimensions='1' type-id='type-id-1'
size-in-bits='infinite' id='type-id-2'>
<subrange length='infinite' type-id='type-id-3' id='type-id-4'/>
</array-type-def>
<var-decl name='is_basic_table' type-id='type-id-2'
mangled-name='is_basic_table' visibility='default'
elf-symbol-id='is_basic_table'/>
<type-decl name='void' id='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
> > 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[2]':
> > size of symbol changed from 4 to 8
> > type of variable changed:
> > type name changed from 'unsigned int[1]' to 'unsigned int[2]'
> > array type size changed from 32 to 64
> > 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?
> >>
> >
> > 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.
Kind regards,
guillermo
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [Bug default/29811] extern array declaration following by its definition reports different sizes in DWARF vs CTF
2022-12-24 15:39 ` guillermo.e.martinez at oracle dot com
@ 2023-01-01 17:50 ` Dodji Seketeli
0 siblings, 0 replies; 12+ messages in thread
From: Dodji Seketeli @ 2023-01-01 17:50 UTC (permalink / raw)
To: guillermo.e.martinez at oracle dot com via Libabigail
Cc: guillermo.e.martinez at oracle dot com
> 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 <is_basic_table>
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug default/29811] extern array declaration following by its definition reports different sizes in DWARF vs CTF
2022-11-21 4:09 [Bug default/29811] New: extern array declaration following by its definition reports different sizes in DWARF vs CTF guillermo.e.martinez at oracle dot com
` (6 preceding siblings ...)
2022-12-24 15:39 ` guillermo.e.martinez at oracle dot com
@ 2023-01-01 17:50 ` dodji at seketeli dot org
2023-01-01 17:57 ` dodji at redhat dot com
8 siblings, 0 replies; 12+ messages in thread
From: dodji at seketeli dot org @ 2023-01-01 17:50 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=29811
--- Comment #5 from dodji at seketeli dot org ---
> 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 <is_basic_table>
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!
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug default/29811] extern array declaration following by its definition reports different sizes in DWARF vs CTF
2022-11-21 4:09 [Bug default/29811] New: extern array declaration following by its definition reports different sizes in DWARF vs CTF guillermo.e.martinez at oracle dot com
` (7 preceding siblings ...)
2023-01-01 17:50 ` dodji at seketeli dot org
@ 2023-01-01 17:57 ` dodji at redhat dot com
8 siblings, 0 replies; 12+ messages in thread
From: dodji at redhat dot com @ 2023-01-01 17:57 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=29811
dodji at redhat dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #6 from dodji at redhat dot com ---
Closing as this seems fixed now.
Thanks taking the time to report this and sorry for the inconvenience!
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread