From: Dodji Seketeli <dodji@seketeli.org>
To: Giuliano Procida <gprocida@google.com>
Cc: libabigail@sourceware.org, kernel-team@android.com,
"Matthias Männich" <maennich@google.com>
Subject: Re: [PATCH 4/7] abidiff: Remove member function diff blank lines.
Date: Mon, 30 Mar 2020 17:22:24 +0200 [thread overview]
Message-ID: <86eet9rhov.fsf@seketeli.org> (raw)
In-Reply-To: <CAGvU0HnA07MT2=E+he+KwNdiv9fU19YK=oOV=5AZuC=q19aGBg@mail.gmail.com> (Giuliano Procida's message of "Mon, 30 Mar 2020 14:50:44 +0000")
Giuliano Procida <gprocida@google.com> a écrit:
[...]
>> > +struct ops {
>> > + // TODO: type, name and size are differnent from deleted_var, but this is
>> > + // still reported as a change rather than a deletion and an addition.
>> > + long added_var;
>> > + virtual long added_fn() { return 0; }
>>
>> This is by design. If a member variable S::foo_member at a given
>> offset/ is replaced by another variable S::bar_member (foo_member and
>> bar_member have the same offset), we chose to detect that foo_member was
>> renamed into bar_member.
>>
>> So I think we can remove that TODO above.
>>
>> Would you agree?
[...]
> I think the TODO has served its purpose which was to attract attention
> (now or in the future). I'll remove it.
Thanks. I am doing it locally here, so you don't need to send another
patch just for that.
[...]
> Here are a couple more worth thinking about:
>
> struct {
> char padding1[16];
> long foo;
> char padding2[8];
> };
>
> struct {
> char padding1[8];
> // did foo move and get renamed?
> long bar;
> char padding2[16];
> };
Here is what abidiff shows for this one (I named the struct 'S'):
$ ~/git/libabigail/master/build/tools/abidiff -l test-v0.o test-v1.o
Leaf changes summary: 1 artifact changed
Changed leaf types summary: 1 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
'struct S at test-v0.c:1:1' changed:
type size hasn't changed
1 data member deletion:
'long int S::foo', at offset 128 (in bits) at test-v0.c:3:1
1 data member insertion:
'long int S::bar', at offset 64 (in bits) at test-v1.c:4:1
there are data member changes:
type 'char[16]' of 'S::padding1' changed:
type name changed from 'char[16]' to 'char[8]'
array type size changed from 128 to 64
array type subrange 1 changed length from 16 to 8
and size changed from 128 to 64 (in bits) (by -64 bits)
type 'char[8]' of 'S::padding2' changed:
type name changed from 'char[8]' to 'char[16]'
array type size changed from 64 to 128
array type subrange 1 changed length from 8 to 16
and offset changed from 192 to 128 (in bits) (by -64 bits), size changed from 64 to 128 (in bits) (by +64 bits)
$
> and
>
> struct {
> bool flag1;
> bool flag2;
> };
>
> struct {
> // flag1 deleted or flag1 renamed and flag2 deleted?
> bool flag2;
> };
And for this one, here is what abidiff shows (I renamed the struct as S
and did s/bool/char/):
$ ~/git/libabigail/master/build/tools/abidiff -l test-v0.o test-v1.o
Leaf changes summary: 1 artifact changed
Changed leaf types summary: 1 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
'struct S at test-v0.c:1:1' changed:
type size changed from 16 to 8 (in bits)
1 data member deletion:
'bool S::flag1', at offset 0 (in bits) at test-v0.c:2:1
there are data member changes:
'bool S::flag2' offset changed from 8 to 0 (in bits) (by -8 bits)
$
Hopefully these change reports should address your (valid!) concerns.
Thanks for looking into this!
Cheers,
--
Dodji
next prev parent reply other threads:[~2020-03-30 15:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-27 14:00 [PATCH 0/7] Mostly whitespace changes and fixes Giuliano Procida
2020-03-27 14:00 ` [PATCH 1/7] abidiff: Clean up new lines between sections Giuliano Procida
2020-03-27 14:00 ` [PATCH 2/7] abidiff: Remove blank line after base class diffs Giuliano Procida
2020-03-27 14:00 ` [PATCH 3/7] abidiff: Fix enum impacted interfaces blank line Giuliano Procida
2020-03-27 14:00 ` [PATCH 4/7] abidiff: Remove member function diff blank lines Giuliano Procida
2020-03-30 14:13 ` Dodji Seketeli
2020-03-30 14:50 ` Giuliano Procida
2020-03-30 15:22 ` Dodji Seketeli [this message]
2020-03-27 14:00 ` [PATCH 5/7] abidiff: Fix variable declaration formatting Giuliano Procida
2020-03-27 14:00 ` [PATCH 6/7] abidiff: Eliminate leaf mode double blank lines Giuliano Procida
2020-03-27 14:00 ` [PATCH 7/7] abidiff: Remove new lines after parameter diffs Giuliano Procida
2020-03-29 17:29 ` [PATCH 0/7] Mostly whitespace changes and fixes Matthias Maennich
2020-03-31 10:37 ` Dodji Seketeli
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=86eet9rhov.fsf@seketeli.org \
--to=dodji@seketeli.org \
--cc=gprocida@google.com \
--cc=kernel-team@android.com \
--cc=libabigail@sourceware.org \
--cc=maennich@google.com \
/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).