public inbox for libabigail@sourceware.org
 help / color / mirror / Atom feed
From: Dodji Seketeli <dodji@seketeli.org>
To: "guillermo.e.martinez at oracle dot com via Libabigail"
	<libabigail@sourceware.org>
Cc: "guillermo.e.martinez at oracle dot com"
	<sourceware-bugzilla@sourceware.org>
Subject: Re: [Bug default/29811] extern array declaration following by its definition reports different sizes in DWARF vs CTF
Date: Fri, 23 Dec 2022 10:19:31 +0100	[thread overview]
Message-ID: <87o7rumq8s.fsf@seketeli.org> (raw)
In-Reply-To: <bug-29811-9487-Jn4w78IT7e@http.sourceware.org/bugzilla/> (guillermo e. martinez at oracle dot com via Libabigail's message of "Thu, 22 Dec 2022 15:27:05 +0000")

"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

  reply	other threads:[~2022-12-23  9:19 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 [this message]
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
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=87o7rumq8s.fsf@seketeli.org \
    --to=dodji@seketeli.org \
    --cc=libabigail@sourceware.org \
    --cc=sourceware-bugzilla@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).