From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::221]) by sourceware.org (Postfix) with ESMTPS id 8F0E9385CC8F for ; Thu, 5 Oct 2023 13:44:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8F0E9385CC8F 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: by mail.gandi.net (Postfix) with ESMTPSA id 4217124000C; Thu, 5 Oct 2023 13:44:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seketeli.org; s=gm1; t=1696513454; 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=p6UPltn5DaNyJ4MeGRT3kJj9d712aq3GyGxg2aOQ5Nw=; b=ChcGVjv2n0zs08SV3ePIjxVCy/n/FsyMqXunSsCZbFKZSt821HfPg71Ais3lL43MwTh0hD ZNMb1itb7a0GoBtqpP9FDp9br6HUEifxuS3SprKIuBrywmp6/dHjmX7fHUfv/kqutyeVY0 1Ujmmg7RHsT04kvuj6SnUL1oUK+MZR2iP9aNmUTUy3n1TVvoIhcc1vwz8sO5kWegLG1DjN H8A30/ZxXsiZSF951LYmd0dNnB3A7U7gL7dLq2+AFE5dagPyKNVbJDk8qMj/ivo0B2V5FR t943WjJGAmWXmUT7I6v+XNbT5isQA4+qoPlDWnaUUIVx7vNzx4p2DzI4QMvp+A== Received: by localhost (Postfix, from userid 1000) id 6348EB6E87; Thu, 5 Oct 2023 15:44:12 +0200 (CEST) From: Dodji Seketeli To: John Moon Cc: , Trilok Soni , "Satya Durga Srinivasu Prabhala" Subject: Support suppressing data members inserted right before flexible array members (was Re: abidiff improvements for kernel UAPI checker) Organization: Me, myself and I References: <5363161d-8167-284e-e35d-9a8ef20adea9@quicinc.com> <877cu5t7tw.fsf@seketeli.org> <87354tt32o.fsf@seketeli.org> <340b33bd-2b43-9f99-58e1-f1b77a51b48a@quicinc.com> <87sfc42rnw.fsf@seketeli.org> <153dc338-ff1f-4273-1663-e934124e4bcc@quicinc.com> X-Operating-System: CentOS Stream release 9 X-URL: http://www.seketeli.net/~dodji Date: Thu, 05 Oct 2023 15:44:12 +0200 In-Reply-To: (John Moon's message of "Wed, 5 Jul 2023 09:52:21 -0700") Message-ID: <87jzs1fakz.fsf_-_@seketeli.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-GND-Sasl: dodji@seketeli.org X-Spam-Status: No, score=-4.3 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_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hello, John Moon a =C3=A9crit: [...] > To summarize, here are the four usecases we have so far and plans to > address them: [...] > 3. Flex array expansion > - Not sure how to detect/suppress this condition > - Flex arrays can only be at the ends of structs, so we just need > to make sure new struct members come "second to last" So, I have a patch to support this case. It's in the branch https://sourceware.org/git/?p=3Dlibabigail.git;a=3Dshort= log;h=3Drefs/heads/users/dodji/fam-suppr. The commit itself is https://sourceware.org/git/?p=3Dlibabigail.git;a=3Dcom= mit;h=3De609f46734b07b551c1b3dbc1eeb2cea61c4ba34 Here is what the commit log says: Consider this code example: $ cat test-v0.c 1 struct foo 2 { 3 int member0; 4 char pad[]; /* <-- flexible array member. */ 5 }; 6 7 void 8 foo(struct foo * p __attribute__((unused))) 9 { 10 } $ Consider this new version of the code where a data member has been added right before the flexible array member: $ cat -n test-v1.c 1 struct foo 2 { 3 int member0; 4 char member1; /*<-- added member. */ 5 char pad[]; /* <-- flexible array member. */ 6 }; 7 8 void 9 foo(struct foo * p __attribute__((unused))) 10 { 11 } $ Here is what abidiff reports about the change: $ abidiff test-v0.o test-v1.o || echo "returned value: $?" Functions changes summary: 0 Removed, 1 Changed, 0 Added function Variables changes summary: 0 Removed, 0 Changed, 0 Added variable 1 function with some indirect sub-type change: [C] 'function void foo(foo*)' at test-v0.c:8:1 has some indirect = sub-type changes: parameter 1 of type 'foo*' has sub-type changes: in pointed to type 'struct foo' at test-v1.c:1:1: type size changed from 32 to 64 (in bits) 1 data member insertion: 'char member1', at offset 32 (in bits) at test-v1.c:4:1 1 data member change: 'char pad[]' offset changed from 32 to 40 (in bits) (by += 8 bits) returned value: 4 $ This patch allows users to suppress this change report using a new property value to the "has_data_member_inserted_at" property of the [suppress_type] directive. The resulting suppression specification reads: $ cat -n foo.suppr 1 [suppress_type] 2 type_kind =3D struct 3 name =3D foo 4 has_data_member_inserted_at =3D offset_of_flexible_array_da= ta_member 5 has_size_change =3D yes $ With this suppression specification the previous command now gives: $ abidiff --suppr foo.suppr test-v0.o test-v1.o && echo "returned v= alue: $?" Functions changes summary: 0 Removed, 0 Changed (1 filtered out), 0= Added function Variables changes summary: 0 Removed, 0 Changed, 0 Added variable returned value: 0 $ I hope this is close enough to what we expect. If after testing and reviewing this patch it's good enough for you, please let me know so that I can fold it into the WIP branch of the "UAPI checker support" at https://sourceware.org/git/?p=3Dlibabigail.git;a=3Dshortlog;h=3Drefs/heads/= users/dodji/check-uapi-support. Please note that I have filed a bug to track the progress of this overall "check-uapi-support" effort at https://sourceware.org/bugzilla/show_bug.cgi?id=3D30931. Feel free to follow that bug there. You can reply to the bugzilla's emails using your mail user agent. > 4. Anonymous enums > - Not sure how to associate these enums when diffing since their > "made up" names don't always match before/after a patch. As I said in an other email, this task led to the patch set https://inbox.sourceware.org/libabigail/87r0mapspt.fsf@redhat.com/ which is in the branch https://sourceware.org/git/?p=3Dlibabigail.git;a=3Dshortlog;h=3Drefs/heads/= users/dodji/better-anon-enums. I am waiting for your feedback to fold that patch set into the WIP branch "check-uapi-support". > I can try tackling items 1 and 2 if you'd like - just let me know! For > items 3 and 4, can we work up a path forward? [...] Hopefully things are moving somewhat now :-) Cheers, --=20 Dodji