From: "dodji at seketeli dot org" <sourceware-bugzilla@sourceware.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 [thread overview]
Message-ID: <bug-29811-9487-Q0zrWlDFg7@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-29811-9487@http.sourceware.org/bugzilla/>
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.
next prev parent reply other threads:[~2023-01-01 17:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-21 4:09 [Bug default/29811] New: " 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
2022-12-23 9:19 ` Dodji Seketeli
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
2023-01-01 17:50 ` Dodji Seketeli
2023-01-01 17:50 ` dodji at seketeli dot org [this message]
2023-01-01 17:57 ` dodji at redhat dot com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-29811-9487-Q0zrWlDFg7@http.sourceware.org/bugzilla/ \
--to=sourceware-bugzilla@sourceware.org \
--cc=libabigail@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).