From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::226]) by sourceware.org (Postfix) with ESMTPS id BCE4F3858418 for ; Thu, 18 Aug 2022 16:29:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BCE4F3858418 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=seketeli.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=seketeli.org Received: (Authenticated sender: dodji@seketeli.org) by mail.gandi.net (Postfix) with ESMTPSA id 6281AC0005; Thu, 18 Aug 2022 16:29:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seketeli.org; s=gm1; t=1660840149; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wtAdKP0GZYkDqcHnG6kxDFZq1WufCSvLuaA1pkiDP6M=; b=ORt0JgFee1kliQGcYpzUEieY3FZ1kFQshmbhgJuQq2203dkc5S2qbo0NpnZrDnWNX+a8AS 3kGGLU66VCbDAHnNM/BAd/c9p/REGLQY1d4SkabiCKCCYGnKvaitkXjzoIpdKnxvOIVwvg lzhthQqbFxaIqWkYxBVapEcwXZlG8BicDQ4HHkobCqvEHD+FV67jZjFOyBZE+8qKRD7BjQ HaJ1LRFMdmHlULbZ0WY1Xtuz2RZ4iKwm2iaaQ1GmxSK4IhipBavGCQKnl2Bb2nhJrNlxbq 5e1cKJnanY5FOMfXoU301RU3nmZUNgFv+wffPIvGgE50/w/zL0zesGGa5xGScg== Received: by localhost (Postfix, from userid 1000) id DE3A35802BD; Thu, 18 Aug 2022 18:29:07 +0200 (CEST) From: Dodji Seketeli To: Giuliano Procida Cc: woodard@redhat.com, libabigail@sourceware.org, Matthias =?utf-8?Q?M?= =?utf-8?Q?=C3=A4nnich?= Subject: Re: [PATCH 3/3] ir: Consider integral types of same kind and size as equivalent Organization: Me, myself and I References: <87sfms91n0.fsf@redhat.com> <87czdw910h.fsf@seketeli.org> <87edxgm8nm.fsf@redhat.com> X-Operating-System: Fedora 38 X-URL: http://www.seketeli.net/~dodji Date: Thu, 18 Aug 2022 18:29:07 +0200 In-Reply-To: (Giuliano Procida's message of "Tue, 16 Aug 2022 19:10:00 +0100") Message-ID: <877d35ms6k.fsf@seketeli.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list of the Libabigail project List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2022 16:29:13 -0000 Giuliano Procida a =C3=A9crit: > Sorry, I have to be brief... No problem. [...] >> 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. > > I think with so much multi-architecture code about and the difficulty > of (say) ABI > monitoring less common architectures, detecting API changes that will be = ABI > breaks on another architecture seems like a big positive. This is interesting. Historically, I chose to analyse binaries rather than source code precisely because I wanted to compare the ABIs of the binaries directly, architecture per architecture, rather than trying to infer what API change might incur an ABI change. The main assumption is that we do *HAVE* access to the actual binaries. And what I really cared about was actual ABI changes, not API changes. Doing the API compatibility verification came afterwards, in a "nice to have manner", from the request of users over time, like icing on the cake, so to speak. The core of what I wanted really was ABI comparison. It's funny to see how the API side of the requirement got stronger over time. Anyway, I think I get your point. [...] >> >> 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 ab= idw? >> >> >> 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? > > The earlier the re-interpretation is, the less visible it is and the orig= inal > information cannot be recovered. Of course. But keep some information all the way can be more costly than trimming them off early, if we know we don't need them. It's a tradeoff that seems clear in my mind. > Alternatively, isn't this sort of thing exactly what the suppression logi= c in > abidiff is supposed to be used for? Self-comparing the IR from a binary against it's abixml counterpart is supposed to be done without any suppression specification applied. OK, so here is what I am proposing. Either I disable this thing altogether (namely, saying that int, short int, long int and long long int are the same if the types have the same size; note that other integral types are not touched by this) and give up on the self-comparison check failure of the btrfs-progs package or I can use this "abi-only-comparison" only when we do self-comparison check, i.e, when we do abidw --abidiff and abipkgdiff --self-check. I have a candidate patch for the later and the former is even easier to do. @Ben and @Giuliano, what would you prefer? Cheers, --=20 Dodji