From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by sourceware.org (Postfix) with ESMTPS id 237853858D28 for ; Fri, 22 Sep 2023 18:28:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 237853858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=quicinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=quicinc.com Received: from pps.filterd (m0279872.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 38MHFqdr026420; Fri, 22 Sep 2023 18:28:12 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=qcppdkim1; bh=tJj5P6mu82WnqfbYqg+9Y7TznFnK/Gqj+0Jg61mdBwY=; b=fh6b/DZcMmCjv+9915PfNZDfJFDck4qZi7NesZ7UVm/V80qpIGpHy1rvH89oPR2l1FP6 PhDsZNx/JkYByGfiNZ7qDbsv1R7iN1S+kwP/tagc8CNVANKnZAeF+iFZQwIpsWdz2MTj xEZUi9K20Zaw0kvKwpUzEn3o2a/wSpjGmClv6pSlVQ0SJ0dW4RH8ZGgBCnCnkVz8XoqP d+OtzNG6ZjUVqCRDXawUT6omO1vwYb/iSTJ2jMAuNeRAQDjv3dIIXIFuang3TNUwqHpw 2m3lr7OPAcib9CjvIegjq+q4GltnXe56Ypkkp5jE9Jie4r4Z6MTPm5fbLOBez3TxSWr3 xQ== Received: from nalasppmta02.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3t9c50rrcj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Sep 2023 18:28:12 +0000 Received: from nalasex01c.na.qualcomm.com (nalasex01c.na.qualcomm.com [10.47.97.35]) by NALASPPMTA02.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 38MISBaL003660 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Sep 2023 18:28:11 GMT Received: from [10.110.122.174] (10.80.80.8) by nalasex01c.na.qualcomm.com (10.47.97.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.30; Fri, 22 Sep 2023 11:28:10 -0700 Message-ID: <44d76150-3e34-4bef-9970-d321f5bc224c@quicinc.com> Date: Fri, 22 Sep 2023 11:28:10 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: abidiff improvements for kernel UAPI checker Content-Language: en-US To: Dodji Seketeli CC: , Trilok Soni , "Satya Durga Srinivasu Prabhala" References: <5363161d-8167-284e-e35d-9a8ef20adea9@quicinc.com> <877cu5t7tw.fsf@seketeli.org> <87354tt32o.fsf@seketeli.org> <340b33bd-2b43-9f99-58e1-f1b77a51b48a@quicinc.com> <87fs36e8sr.fsf@seketeli.org> <87bkdue89g.fsf@seketeli.org> From: John Moon In-Reply-To: <87bkdue89g.fsf@seketeli.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01c.na.qualcomm.com (10.47.97.35) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: MVgIYWCKKn925Rx7l5UMOu7GIvYL8Xym X-Proofpoint-ORIG-GUID: MVgIYWCKKn925Rx7l5UMOu7GIvYL8Xym X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-09-22_16,2023-09-21_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 malwarescore=0 bulkscore=0 suspectscore=0 mlxlogscore=907 spamscore=0 impostorscore=0 priorityscore=1501 mlxscore=0 adultscore=0 phishscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2309180000 definitions=main-2309220159 X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,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: On 9/22/2023 4:51 AM, Dodji Seketeli wrote: > Hey again, > > [...] > > Dodji Seketeli a écrit: > >> So, I have an initial implementation for handling the comparison of >> anonymous enums and it's in the 'users/dodji/better-anon-enums' branch. > > I forgot to add a link to the branch. It's at > https://sourceware.org/git/?p=libabigail.git;a=shortlog;h=refs/heads/users/dodji/better-anon-enums. > > So cloning it is via: > > $ git clone git://sourceware.org/git/libabigail.git -b users/dodji/better-anon-enums > > [...] > > Cheers, > Hi Dodji, Thanks for the quick turnaround! I gave this a try on my end and it looks like the patch is doing what it's supposed to, but it's not producing the desired behavior. Let's zoom in on this example: https://github.com/torvalds/linux/commit/1d91855304c2046115ee10be2c93161d93d5d40d (specifically, the change to include/uapi/rdma/hns-abi.h: enum { HNS_ROCE_EXSGE_FLAGS = 1 << 0, HNS_ROCE_RQ_INLINE_FLAGS = 1 << 1, + HNS_ROCE_CQE_INLINE_FLAGS = 1 << 2, }; enum { HNS_ROCE_RSP_EXSGE_FLAGS = 1 << 0, HNS_ROCE_RSP_RQ_INLINE_FLAGS = 1 << 1, + HNS_ROCE_RSP_CQE_INLINE_FLAGS = 1 << 2, }; Before your patch, abidiff reports: [C] 'enum __anonymous_enum__1' changed: type size hasn't changed 2 enumerator deletions: '__anonymous_enum__1::HNS_ROCE_RSP_EXSGE_FLAGS' value '1' '__anonymous_enum__1::HNS_ROCE_RSP_RQ_INLINE_FLAGS' value '2' 3 enumerator insertions: '__anonymous_enum__::HNS_ROCE_EXSGE_FLAGS' value '1' '__anonymous_enum__::HNS_ROCE_RQ_INLINE_FLAGS' value '2' '__anonymous_enum__::HNS_ROCE_CQE_INLINE_FLAGS' value '4' 1 added type unreachable from any public interface: [A] 'enum __anonymous_enum__1' at hns-abi.h:94:1 After your patch: 2 removed types unreachable from any public interface: [D] 'enum {HNS_ROCE_EXSGE_FLAGS=1, HNS_ROCE_RQ_INLINE_FLAGS=2, }' at hns-abi.h:88:1 [D] 'enum {HNS_ROCE_RSP_EXSGE_FLAGS=1, HNS_ROCE_RSP_RQ_INLINE_FLAGS=2, }' at hns-abi.h:93:1 2 added types unreachable from any public interface: [A] 'enum {HNS_ROCE_CQE_INLINE_FLAGS=4, HNS_ROCE_EXSGE_FLAGS=1, HNS_ROCE_RQ_INLINE_FLAGS=2, }' at hns-abi.h:88:1 [A] 'enum {HNS_ROCE_RSP_CQE_INLINE_FLAGS=4, HNS_ROCE_RSP_EXSGE_FLAGS=1, HNS_ROCE_RSP_RQ_INLINE_FLAGS=2, }' at hns-abi.h:94:1 I probably should have thought of this before, but simply changing the anon enum's "name" to be a concatenation of members wouldn't work to associate them across a diff. When you add a new enum variant, the "name" of the enum changes too, so abidiff thinks they're different enums. I've given it a bit of thought and I'm not sure how the two enums could be associated when diffing... I'm not sure if the diff corpus has any context-awareness that could help here. Maybe you can think of something clever? If not, I think this output is at least easier to post-process! For example, I could add logic to the script to do something like "if there's a deleted enum whose contents are present in an added enum, assume it's an addition to an anonymous enum and ignore". Let me know what you think! Thanks, John