public inbox for libabigail@sourceware.org
 help / color / mirror / Atom feed
From: Dodji Seketeli <dodji@seketeli.org>
To: Giuliano Procida <gprocida@google.com>
Cc: "Dodji Seketeli" <dodji@seketeli.org>,
	"Dodji Seketeli via Libabigail" <libabigail@sourceware.org>,
	"Matthias Männich" <maennich@google.com>
Subject: Re: [PATCH 3/3] ir: Consider integral types of same kind and size as equivalent
Date: Tue, 16 Aug 2022 18:54:05 +0200	[thread overview]
Message-ID: <87edxgm8nm.fsf@redhat.com> (raw)
In-Reply-To: <CAGvU0Hk6MM6b0EE+Y+XfQSXipCRpfEYSFoQ_NNw+p0TxnpapGw@mail.gmail.com> (Giuliano Procida's message of "Wed, 10 Aug 2022 16:23:59 +0100")

Giuliano Procida <gprocida@google.com> writes:

> Hi Dodji.

Hello Giuliano,

[...]

> On Sat, 23 Jul 2022 at 00:33, Dodji Seketeli <dodji@seketeli.org> wrote:
>>
>> Hello,
>>
>> On some platforms, "long int" and "long long int" can have the same
>> size.  In that case, we want those two types to be equivalent from ABI
>> standpoint.  Otherwise, through the use of typedefs and pointers, two
>> structs "C" defined in different translation units where one uses
>> "long int" in a translation unit and "long long int" in another should
>> be considered ABI compatible if long int and long long int have the
>> same size on that platform.
>
> While such types may be ABI compatible, they are not API compatible as they
> impact (at least) C++ overload resolution.

Right.  But as usual with these things (API vs ABI conformance), we try
to accommodate people's need as much as possible, with a preference with
ABI conformance when we can't ensure both at the same time.  That's what
we have done historically, but of course, my stance is not cast in
stone.  I am open to discussion and change.

In this particular case of /C type/ program, it seems to be that the
programmers expect the types to be ABI compatible.

C++ of course being strongly type as it is, I understand that we might
want to be stricter.

> All of char, unsigned char, signed char, int, unsigned, long, etc. are
> distinct types.
> Conflating some subsets of these will result in confusing ABI
> difference reports.

For C++ (or Ada, or in those strongly type languages) I think I
understand why some change reports might be confusing.  In your mind,
can we have the issue with C however? (real question).


>> Otherwise, that causes spurious type changes that lead to self
>> comparison change down the road.  For instance, the following command
>> fails:
>>
>>     $ tools/fedabipkgdiff --debug --self-compare -a --from fc36 btrfs-progs
>
> Shouldn't any tweaking of behaviour happen with abidiff rather than abidw?


I am not sure to understand the question.  This kind of adjustment of
what is is read from the binary typically tends to happen at the core
level (either DWARF reader, IR construction/transformation, comparison,
etc) rather at the level of a specific tool.  Am I missing something
from what you have in mind?

>
> We might not end up with stable XML but the finger of blame should be
> pointed at the btrfs-progs in any case.

I understand and I sympathesize with your point of view.  But just to
explain where I sit on the matter, there have unfortunately been plenty
of real life cases where the programs (those written by the app/library
developers or by the compiler/linker developers) are not what libabigail
would expect in a perfect world.  So far we try hard to "accommodate"
when we can, if that can lead to a better experience for libabigail
users.  But I agree that we shouldn't try harder.  I guess knowing the
difference is the crux of this art.  So I am open to discussion to try
to accommodate your point of view too.

>> This patch thus changes the comparison engine of the IR so that the
>> "short, long and long long" modifiers don't change the result of
>> comparing integral types that share the same base type when they have
>> the same size.
>
> We don't want this behaviour and can carry a revert patch in AOSP or
> work a way to disable it that is less likely to cause merge conflicts
> in the future.

Would it be useful for your case if this behaviour happens just for C
programs?

> Is there an easy way of putting this under flag control?

I guess so, yes.  But just a flag would not be optimal from a user
standpoint, would it?

Thank you for raising this and sorry for the inconvenience.

I hope we resolve this.

Cheers,

-- 
		Dodji

  parent reply	other threads:[~2022-08-16 16:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-22 23:19 [PATCH 0/3] Make integral types of same base and size compatible Dodji Seketeli
2022-07-22 23:28 ` [PATCH 1/3] ir: Disambiguate sorting of array element types Dodji Seketeli
2022-07-22 23:31 ` [PATCH 2/3] dwarf-reader: Remove redundant qualifiers from qualified types Dodji Seketeli
2022-07-22 23:32 ` [PATCH 3/3] ir: Consider integral types of same kind and size as equivalent Dodji Seketeli
2022-08-10 15:23   ` Giuliano Procida
2022-08-11  2:22     ` Ben Woodard
2022-08-12 15:26       ` Giuliano Procida
2022-08-16 19:56         ` Ben Woodard
2022-08-16 16:54     ` Dodji Seketeli [this message]
2022-08-16 17:06       ` Ben Woodard
2022-08-16 18:10       ` Giuliano Procida
2022-08-18 16:29         ` Dodji Seketeli
2022-08-18 17:52           ` Ben Woodard
2022-08-19 15:30             ` 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=87edxgm8nm.fsf@redhat.com \
    --to=dodji@seketeli.org \
    --cc=gprocida@google.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).