From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by sourceware.org (Postfix) with ESMTPS id 10EDA3857B89 for ; Thu, 7 Jul 2022 20:25:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 10EDA3857B89 Received: from pps.filterd (m0246632.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 267KCvFf020796; Thu, 7 Jul 2022 20:24:57 GMT Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta01.appoci.oracle.com [138.1.114.2]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3h4uby6bb6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 07 Jul 2022 20:24:56 +0000 Received: from pps.filterd (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (8.16.1.2/8.16.1.2) with SMTP id 267KBKxu015938; Thu, 7 Jul 2022 20:24:55 GMT Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2100.outbound.protection.outlook.com [104.47.55.100]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com with ESMTP id 3h4ud656y9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 07 Jul 2022 20:24:55 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=My0tpv0CpRQmkn5Zj9aEtMsCTXZHPxCXrCgFmGM3FxvjVG0mZD9T+X0Rj5Av/w1YySFm21Z1Q+a3rD/xG2HBjL/Jb7lthOjOCsrwDo/kMpfFzPGAK9/oK0Dk8K9nzRBpCr+qNoYXG7F3jy8TJul8YuB0y1ABRA0CabkUsKmAjtc2V425Np0VEQQM02IgwD9s/qlVvWsGfxcIErm4c9bWJTL93lwWEKBW2aRuMaUqHqH+o9OJwHiUTqsrA1I5dFhF+lle+c19zjrAXVK9JWMSh/pliR+5TgWQuk0H2KOeN9CII2VR+ADeSqu5to0JXtUvEVEKw3q6zExLMjPgr+Se+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3AjN0EWVcP8b9lIh+s+Lr8Lqw7SjQBdDqY2dd0JypDI=; b=iuRcRLrHo+1s+ee/93sqdIIBXq0Zenj84suMZeVF8zyw6r4nm0PS2ZDC9QshOfwvx2BQhW0CqidFj0MdwBQIoypjQMXr/Lg6PWFXZDzagnkuqZaASMxoJmUj22FTF1UNwrmvLuAfOMr9xrY11HDxhNB9L2w17CQhpnTj76CH4FN4v7uX8XX/lVTP1r2xsHpzp+6Z75kGf9a5UIhWGuJUT446xfNbj4f6GkNpg6krZq6Y3VxYR6Kfm1eypAJb9yKMR5FA31J1riqfhbMDP9fdGF+2o4uoCtQWwLZbX33eTCTpdiudgeh0vZQTfLr0sUdO3w745MQdgwPWGOAO3Lq4Sw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none Received: from BYAPR10MB2888.namprd10.prod.outlook.com (2603:10b6:a03:88::32) by CY4PR1001MB2119.namprd10.prod.outlook.com (2603:10b6:910:3f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.17; Thu, 7 Jul 2022 20:24:52 +0000 Received: from BYAPR10MB2888.namprd10.prod.outlook.com ([fe80::287e:5ffc:d595:8316]) by BYAPR10MB2888.namprd10.prod.outlook.com ([fe80::287e:5ffc:d595:8316%6]) with mapi id 15.20.5395.020; Thu, 7 Jul 2022 20:24:52 +0000 From: "Jose E. Marchesi" To: Yonghong Song Cc: David Faust , gcc-patches@gcc.gnu.org Subject: Re: kernel sparse annotations vs. compiler attributes and debug_annotate_{type,decl} WAS: Re: [PATCH 0/9] Add debug_annotate attributes References: <20220607214342.19463-1-david.faust@oracle.com> <2ab1d9a1-0077-a1e7-f212-556fcf8c8883@fb.com> <9bd41e20-5c39-0d35-bd6e-c10c65280da7@oracle.com> <52dcfdb6-f1b9-1986-5d10-8d6ac8c6d256@fb.com> <874k0jfbu0.fsf_-_@oracle.com> <87edziknc1.fsf@oracle.com> <0c104e7b-1873-c141-37b9-71444f585793@fb.com> Date: Thu, 07 Jul 2022 22:24:39 +0200 In-Reply-To: <0c104e7b-1873-c141-37b9-71444f585793@fb.com> (Yonghong Song's message of "Fri, 24 Jun 2022 11:01:04 -0700") Message-ID: <87let4isc8.fsf@oracle.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0236.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a7::7) To BYAPR10MB2888.namprd10.prod.outlook.com (2603:10b6:a03:88::32) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e0948193-731f-4b98-8b6c-08da6056bcc3 X-MS-TrafficTypeDiagnostic: CY4PR1001MB2119:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: EKzdiXchBGa70zSt2Ri5mZAqJc4dVuqKl4Ph/Oblj6Wyr6UFZY0PhMD9ym721ZtHgQ8penX28rDTZXZcEeEoX19w2g9I5SDLBHLq9CZYLuHMIg2Y12voM0rjAwuxq2ed7SwKriw6DqhlBWShcc3Sh4w2xmC3Q74olPphjHHNhD5rNI8XSfJPUO1+elHPzeqj/JoI1Hb7T8noohePQOd7HOVNr6wdLb/I4PW7hkkgIwBfu7xlr/q9xK7K8FnoqK/JES/6SbGFHUpvm3n1KmorVcfHBZTiZl5GIGyORKyoUbvAeZSgBSf+3QVICYkItVpeUW7uH9TmDAu3l21zqueD20EXMipTU2siu4NqOBobgA2tMK77OjfEVdDsppeg152+oZGG6wSinLqkZTS99wPEf79miduMG+ghV96djiwoMRhUIkDd1JzRswXAO7iAg6leFc7/AjVO+U8U5ges+PmwpbfVbc3/dTuLJKfL0kbV44WuJ+YVUAfqtIVvLsRFDftlyKyUa9rjqYQNS2OqD2SUTWpzSKfbdbAehWofrjJJNN/rntLk5FhRA9Lcibb1vnU+f/1KwMlNlhx+Z+O4TuKLrEkgDae8fvGl77TbxwoV9lJh5xcCy+BgFbxihMf/KvgGhj9syCZeC+udjOJ5W5g4DJNzkbrKHrX9ZolYyS9S2v2/P+/0QIi2/mx8Z3GeP/M/f3ZKiL1fw+nQjs+arDHlDDvlcBwwtWesFpgq4bhjPjvweLd2NRnGIaU2P63mhJ+h2cXDBtC5Eq3iDKljq1cUHUhRrEisipsjVVDyBpiQ8rmKZcSlG3/39FKhbZKl6oiqVot/lS4bAP5vaF3lTP5MhMmzfUbqxXBCl2nnVVMpYYIpjCGOu+vR5/lUIHXpXl+j X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR10MB2888.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(136003)(39860400002)(346002)(376002)(366004)(396003)(6916009)(36756003)(186003)(6512007)(30864003)(6666004)(8936002)(86362001)(316002)(26005)(5660300002)(53546011)(52116002)(966005)(8676002)(38100700002)(66476007)(66556008)(4326008)(66946007)(83380400001)(38350700002)(478600001)(6506007)(41300700001)(6486002)(2906002)(2616005); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?cPSFbYDVzSUPcLVWU5AlU1cO2OZALTSDviDIWvb5vREgywUHpM9IcJla6Z0i?= =?us-ascii?Q?+x389dXLHEWjLBhplUH0TEMyj2BtfOmT3yzx4+vsmsRXdl7+mhqTsbna8Jki?= =?us-ascii?Q?D9CWisYEptrdCd5uvzPaBY4IEfXHgbZHW1UUqEUXlI93M/0cP+vZo7LH9LqL?= =?us-ascii?Q?NDUSmvN5bntTZ5r9DmbLUq37NwlI3XmVCCW6ynFcgZI9UDcFLYPze23QzHN9?= =?us-ascii?Q?qoUAz4gtmD4GFjybnbnGEYTC8V4uvB0ShgQ+ZZr4x0m6/3j9vRf7pEoWEVjw?= =?us-ascii?Q?ej4togQmXOfJQ+7LKvFJEw25YpMJRYAtg6xLCM5ZznuKtxBkGpKorxCjKwr4?= =?us-ascii?Q?sk0ZeN6MFPfR/EnpKiU8M4Kl8hfnpmbtvBwwdovC08LHenJkngcpohjMksTL?= =?us-ascii?Q?gKh0HXQCkSfNuHr8efDy2SG/yHXsYOscjhM+hzMydl191/qMpiVKdYu1JGQs?= =?us-ascii?Q?IlWgE7nYuOo762cxnaAezVGeExB0tXyD0FAhvlZ1K+UK+C3bnhuO9+V7LcSR?= =?us-ascii?Q?y2Znf9l/E7SmRYmB/sGHhm4SIX9+1V1bgCSeE+hyYgQE8YVLzDhOtpMEeRMB?= =?us-ascii?Q?/5/dRckRQW4I68QlVNni0BiDASJRLDkcjpjycFAhEpClJl2As6iHbAwyREBK?= =?us-ascii?Q?zvNxoMahuCU81n6zMYb2pH+16MPq0pXOg8abHLvMIUNIuGhxMmk06aL2vQpS?= =?us-ascii?Q?QMMFdSycfQO/EVzMq1ChiIhScHO7/V6BOGCbVn6JBSXbEy7iuFGYJf3692cy?= =?us-ascii?Q?Tb3a3TdCsp5Ueti8ufoJBw2BjHaT1uT7ZiJd9Emk7d9o/Mv/eCccffONFyq3?= =?us-ascii?Q?4dVNa+0oJsTxgeghxgnyoaqK0zY7lpdU6eJI+6ApYSClR38YDv/GozLJMUDW?= =?us-ascii?Q?x44wpUL9dHFMSnVf6fJaPI3qpeNz4Zk4thEJ0l2e09w8Ufajz07nLmv5Sz3N?= =?us-ascii?Q?b+ASHWMuSMs16hw2MMrV4UcPtdvKKj+nDnBt8LPsGPbbYmijtHO72Gi6KDRL?= =?us-ascii?Q?ofljQM8RcVA3S6L3AWvvizseImzpo6UlsJsD9Yg42RNiQi+o2S5z51HK54Ab?= =?us-ascii?Q?9shRiEgleDZDeHksx60WmPf538l78R/bovCSrb4NiuZsS5jqAO98fm9CEPKq?= =?us-ascii?Q?eUFOThvM0QiRCCtEOVwnRLi1FbCXrwgXKKFLpDJAqAyO/dOgA5RgTtZsOsSv?= =?us-ascii?Q?yEJk0BTBFVhM6/31qJiC8SpyUzSxQYxBdwLgRnteCboN4D+pSKWzJS0vDE+6?= =?us-ascii?Q?xX7pbIq5O8ak7KdQXk1SnHJ3e+gsInwLNfqDkQMcHD94yC3EhSa/YAmaIGmP?= =?us-ascii?Q?rI/h7xYuWWG2OnWajpRutEM+OblIW8b9XWYuHHBwVRSNPXCeU1tNNs7S6vOe?= =?us-ascii?Q?bRWYLsEaReaUFNgMgwXrVN4iUtR0X29UOX2PnzoJufcOfFRfhbAyvOOZ9/9m?= =?us-ascii?Q?5hdq7lI7NLs2aWW7gsX7PgN1dO8m5hFZn4XtwC2ezRc5a9FdBuJyLhGdTrWp?= =?us-ascii?Q?ql1D4/i67AOJP3fybjeJ1hJYpywqLk/bs4qVpHjKcGpQF7e9NJlWWJzgo5sF?= =?us-ascii?Q?HnetK9qEWaLhAQaMvzkv59BxqRvpmBeo5EMNBRgYH1Ddr9B8ZVEu9kIesh9b?= =?us-ascii?Q?bQ=3D=3D?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: e0948193-731f-4b98-8b6c-08da6056bcc3 X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB2888.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jul 2022 20:24:51.9229 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: QQzuAh+ocp6U022I08M7ElReluserNbB2uCiq/X2d6+YijGEne0dCb5h3VaDAzYXND3w+pIb4HUd6gr43maGAPCWltL3dLgj2Z2pIL6Z8TA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1001MB2119 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517, 18.0.883 definitions=2022-07-07_17:2022-06-28, 2022-07-07 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 suspectscore=0 spamscore=0 mlxlogscore=999 phishscore=0 malwarescore=0 mlxscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2207070081 X-Proofpoint-ORIG-GUID: oFOivJ3IRh4JBFZAIr_R1FfAavLRy7Ic X-Proofpoint-GUID: oFOivJ3IRh4JBFZAIr_R1FfAavLRy7Ic X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, 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: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2022 20:25:47 -0000 Hi Yonghong. > On 6/21/22 9:12 AM, Jose E. Marchesi wrote: >> >>> On 6/17/22 10:18 AM, Jose E. Marchesi wrote: >>>> Hi Yonghong. >>>> >>>>> On 6/15/22 1:57 PM, David Faust wrote: >>>>>> >>>>>> On 6/14/22 22:53, Yonghong Song wrote: >>>>>>> >>>>>>> >>>>>>> On 6/7/22 2:43 PM, David Faust wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> This patch series adds support for: >>>>>>>> >>>>>>>> - Two new C-language-level attributes that allow to associate (to "annotate" or >>>>>>>> to "tag") particular declarations and types with arbitrary strings. As >>>>>>>> explained below, this is intended to be used to, for example, characterize >>>>>>>> certain pointer types. >>>>>>>> >>>>>>>> - The conveyance of that information in the DWARF output in the form of a new >>>>>>>> DIE: DW_TAG_GNU_annotation. >>>>>>>> >>>>>>>> - The conveyance of that information in the BTF output in the form of two new >>>>>>>> kinds of BTF objects: BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG. >>>>>>>> >>>>>>>> All of these facilities are being added to the eBPF ecosystem, and support for >>>>>>>> them exists in some form in LLVM. >>>>>>>> >>>>>>>> Purpose >>>>>>>> ======= >>>>>>>> >>>>>>>> 1) Addition of C-family language constructs (attributes) to specify free-text >>>>>>>> tags on certain language elements, such as struct fields. >>>>>>>> >>>>>>>> The purpose of these annotations is to provide additional information about >>>>>>>> types, variables, and function parameters of interest to the kernel. A >>>>>>>> driving use case is to tag pointer types within the linux kernel and eBPF >>>>>>>> programs with additional semantic information, such as '__user' or '__rcu'. >>>>>>>> >>>>>>>> For example, consider the linux kernel function do_execve with the >>>>>>>> following declaration: >>>>>>>> >>>>>>>> static int do_execve(struct filename *filename, >>>>>>>> const char __user *const __user *__argv, >>>>>>>> const char __user *const __user *__envp); >>>>>>>> >>>>>>>> Here, __user could be defined with these annotations to record semantic >>>>>>>> information about the pointer parameters (e.g., they are user-provided) in >>>>>>>> DWARF and BTF information. Other kernel facilites such as the eBPF verifier >>>>>>>> can read the tags and make use of the information. >>>>>>>> >>>>>>>> 2) Conveying the tags in the generated DWARF debug info. >>>>>>>> >>>>>>>> The main motivation for emitting the tags in DWARF is that the Linux kernel >>>>>>>> generates its BTF information via pahole, using DWARF as a source: >>>>>>>> >>>>>>>> +--------+ BTF BTF +----------+ >>>>>>>> | pahole |-------> vmlinux.btf ------->| verifier | >>>>>>>> +--------+ +----------+ >>>>>>>> ^ ^ >>>>>>>> | | >>>>>>>> DWARF | BTF | >>>>>>>> | | >>>>>>>> vmlinux +-------------+ >>>>>>>> module1.ko | BPF program | >>>>>>>> module2.ko +-------------+ >>>>>>>> ... >>>>>>>> >>>>>>>> This is because: >>>>>>>> >>>>>>>> a) Unlike GCC, LLVM will only generate BTF for BPF programs. >>>>>>>> >>>>>>>> b) GCC can generate BTF for whatever target with -gbtf, but there is no >>>>>>>> support for linking/deduplicating BTF in the linker. >>>>>>>> >>>>>>>> In the scenario above, the verifier needs access to the pointer tags of >>>>>>>> both the kernel types/declarations (conveyed in the DWARF and translated >>>>>>>> to BTF by pahole) and those of the BPF program (available directly in BTF). >>>>>>>> >>>>>>>> Another motivation for having the tag information in DWARF, unrelated to >>>>>>>> BPF and BTF, is that the drgn project (another DWARF consumer) also wants >>>>>>>> to benefit from these tags in order to differentiate between different >>>>>>>> kinds of pointers in the kernel. >>>>>>>> >>>>>>>> 3) Conveying the tags in the generated BTF debug info. >>>>>>>> >>>>>>>> This is easy: the main purpose of having this info in BTF is for the >>>>>>>> compiled eBPF programs. The kernel verifier can then access the tags >>>>>>>> of pointers used by the eBPF programs. >>>>>>>> >>>>>>>> >>>>>>>> For more information about these tags and the motivation behind them, please >>>>>>>> refer to the following linux kernel discussions: >>>>>>>> >>>>>>>> https://lore.kernel.org/bpf/20210914223004.244411-1-yhs@fb.com/ >>>>>>>> https://lore.kernel.org/bpf/20211012164838.3345699-1-yhs@fb.com/ >>>>>>>> https://lore.kernel.org/bpf/20211112012604.1504583-1-yhs@fb.com/ >>>>>>>> >>>>>>>> >>>>>>>> Implementation Overview >>>>>>>> ======================= >>>>>>>> >>>>>>>> To enable these annotations, two new C language attributes are added: >>>>>>>> __attribute__((debug_annotate_decl("foo"))) and >>>>>>>> __attribute__((debug_annotate_type("bar"))). Both attributes accept a single >>>>>>>> arbitrary string constant argument, which will be recorded in the generated >>>>>>>> DWARF and/or BTF debug information. They have no effect on code generation. >>>>>>>> >>>>>>>> Note that we are not using the same attribute names as LLVM (btf_decl_tag and >>>>>>>> btf_type_tag, respectively). While these attributes are functionally very >>>>>>>> similar, they have grown beyond purely BTF-specific uses, so inclusion of "btf" >>>>>>>> in the attribute name seems misleading. >>>>>>>> >>>>>>>> DWARF support is enabled via a new DW_TAG_GNU_annotation. When generating DWARF, >>>>>>>> declarations and types will be checked for the corresponding attributes. If >>>>>>>> present, a DW_TAG_GNU_annotation DIE will be created as a child of the DIE for >>>>>>>> the annotated type or declaration, one for each tag. These DIEs link the >>>>>>>> arbitrary tag value to the item they annotate. >>>>>>>> >>>>>>>> For example, the following variable declaration: >>>>>>>> >>>>>>>> #define __typetag1 __attribute__((debug_annotate_type ("typetag1"))) >>>>>>>> >>>>>>>> #define __decltag1 __attribute__((debug_annotate_decl ("decltag1"))) >>>>>>>> #define __decltag2 __attribute__((debug_annotate_decl ("decltag2"))) >>>>>>>> >>>>>>>> int * __typetag1 x __decltag1 __decltag2; >>>>>>> >>>>>>> Based on the above example >>>>>>> static int do_execve(struct filename *filename, >>>>>>> const char __user *const __user *__argv, >>>>>>> const char __user *const __user *__envp); >>>>>>> >>>>>>> Should the above example should be the below? >>>>>>> int __typetag1 * x __decltag1 __decltag2 >>>>>>> >>>>>> This example is not related to the one above. It is just meant to >>>>>> show the behavior of both attributes. My apologies for not making >>>>>> that clear. >>>>> >>>>> Okay, it should be fine if the dwarf debug_info is shown. >>>>> >>>>>> >>>>>>>> >>>>>>>> Produces the following DWARF information: >>>>>>>> >>>>>>>> <1><1e>: Abbrev Number: 3 (DW_TAG_variable) >>>>>>>> <1f> DW_AT_name : x >>>>>>>> <21> DW_AT_decl_file : 1 >>>>>>>> <22> DW_AT_decl_line : 7 >>>>>>>> <23> DW_AT_decl_column : 18 >>>>>>>> <24> DW_AT_type : <0x49> >>>>>>>> <28> DW_AT_external : 1 >>>>>>>> <28> DW_AT_location : 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0) >>>>>>>> <32> DW_AT_sibling : <0x49> >>>>>>>> <2><36>: Abbrev Number: 1 (User TAG value: 0x6000) >>>>>>>> <37> DW_AT_name : (indirect string, offset: 0xd6): debug_annotate_decl >>>>>>>> <3b> DW_AT_const_value : (indirect string, offset: 0xcd): decltag2 >>>>>>>> <2><3f>: Abbrev Number: 1 (User TAG value: 0x6000) >>>>>>>> <40> DW_AT_name : (indirect string, offset: 0xd6): debug_annotate_decl >>>>>>>> <44> DW_AT_const_value : (indirect string, offset: 0x0): decltag1 >>>>>>>> <2><48>: Abbrev Number: 0 >>>>>>>> <1><49>: Abbrev Number: 4 (DW_TAG_pointer_type) >>>>>>>> <4a> DW_AT_byte_size : 8 >>>>>>>> <4b> DW_AT_type : <0x5d> >>>>>>>> <4f> DW_AT_sibling : <0x5d> >>>>>>>> <2><53>: Abbrev Number: 1 (User TAG value: 0x6000) >>>>>>>> <54> DW_AT_name : (indirect string, offset: 0x9): debug_annotate_type >>>>>>>> <58> DW_AT_const_value : (indirect string, offset: 0x1d): typetag1 >>>>>>>> <2><5c>: Abbrev Number: 0 >>>>>>>> <1><5d>: Abbrev Number: 5 (DW_TAG_base_type) >>>>>>>> <5e> DW_AT_byte_size : 4 >>>>>>>> <5f> DW_AT_encoding : 5 (signed) >>>>>>>> <60> DW_AT_name : int >>>>>>>> <1><64>: Abbrev Number: 0 >>>>> >>>>> This shows the info in .debug_abbrev. What I mean is to >>>>> show the related info in .debug_info section which seems more useful to >>>>> understand the relationships between different tags. Maybe this is due >>>>> to that I am not fully understanding what <1>/<2> means in <1><49> and >>>>> <2><53> etc. >>>> I think that dump actually shows .debug_info, with the abbrevs >>>> expanded... >>>> Anyway, it seems to us that the root of this problem is the fact the >>>> kernel sparse annotations, such as address_space(__user), are: >>>> 1) To be processed by an external kernel-specific tool ( >>>> https://sparse.docs.kernel.org/en/latest/annotations.html) and not a >>>> C compiler, and therefore, >>>> 2) Not quite the same than compiler attributes (despite the way they >>>> look.) In particular, they seem to assume an ordering different than >>>> of GNU attributes: in some cases given the same written order, they >>>> refer to different things!. Which is quite unfortunate :( >>> >>> Yes, currently __user/__kernel macros (implemented with address_space >>> attribute) are processed by macros. >>> >>>> Now, if I understood properly, you plan to change the definition of >>>> __user and __kernel in the kernel sources in order to generate the tag >>>> compiler attributes, correct? >>> >>> Right. The original __user definition likes: >>> # define __user __attribute__((noderef, address_space(__user))) >>> >>> The new attribute looks like >>> # define BTF_TYPE_TAG(value) __attribute__((btf_type_tag(#value))) >>> # define __user BTF_TYPE_TAG(user) >> Ok I see. So the kernel will stop using sparse attributes to >> implement >> __user and __kernel and start using compiler attributes for tags >> instead. >> >>>> Is that the reason why LLVM implements what we assume to be the >>>> sparse >>>> ordering, and not the correct GNU attributes ordering, for the tag >>>> attributes? >>> >>> Note that __user attributes apply to pointee's and not pointers. >>> Just like >>> const int *p; >>> the 'const' is not applied to pointer 'p', but the pointee of 'p'. >>> >>> What current llvm dwarf generation with >>> pointer >>> <--- btf_type_tag >>> is just ONE implementation. As I said earlier, I am okay to >>> have dwarf implementation like >>> p->btf_type_tag->const->int. >>> If you can propose an implementation like this in dwarf. I can propose >>> to change implementation in llvm. >> I think we are miscommunicating. >> Looks like there is a divergence on what attributes apply to what >> language entities between the sparse compiler and GCC/LLVM. How to >> represent that in DWARF is a different matter. >> For this example: >> int __typetag1 * __typetag2 __typetag3 * g; >> a) GCC associates __typetag1 with the pointer-to-pointer-to-int. >> b) LLVM associates __typetag1 to pointer-to-int. >> Where: >> a) Is the expected behavior of a compiler attributes, as documented >> in >> the GCC manual. >> b) Is presumably what the sparse compiler expects, but _not_ the >> ordering expected for a compiler GNU attribute. >> So, if the kernel source __user and __kernel annotations (which >> currently expand to sparse attributes) follow the sparse ordering, and >> you want to implement __user and __kernel in terms of compiler >> attributes instead (the annotation attributes) then you will have to: >> 1) Fix LLVM to implement the usual ordering for these attributes and >> 2) fix the kernel sources to use that ordering >> [Incidentally, the same applies to another "ex-sparse" attribute you >> have in the kernel and also implemented in LLVM with a weird ordering: >> the address_space attribute.] >> For 2), it may be possible to write a coccinnelle script to generate >> the >> patch... > > I don't think (2) (to change kernel source for different attr ordering) > will work. So the only thing we can do is in compiler/pahole except > macro replacement in kernel. I looked at sparse and its parser. Wanted to be sure the ordering it uses to interpret sparse annotations (such as address_space, alignment, etc) is definitely _not_ the same ordering used by __attribute__ in C compilers. It is very different indeed and the same can be said about how sparse interprets other modifiers like `const': in sparse both `int const *foo' and `int *const foo' parse to a constant pointer to int, for example. I am not to judge how sparse handles its annotations. It may be very well and pertinent for its particular purpose. But I am not sure if it is reasonable to expect C compilers to implement certain type __attributes__ to parse differently, just because it happens these attributes are reused from sparse annotations in a particular program (in this case the kernel.) The debug_annotate_decl and debug_annotate_type attributes are not even intended to be kernel-specific. So, if changing the kernel sources is not an option (why btw, other than being a PITA?) at this point I really don't know what else to suggest :/ Any suggestion from the front-end people? >> Does this make sense? >> >>>> If that is so, we have quite a problem here: I don't think we can >>>> change >>>> the way GCC handles GNU-like attributes just because the kernel sources >>>> want to hook on these __user/__kernel sparse annotations to generate the >>>> compiler tags, even if we could mayhaps get GCC to handle >>>> debug_annotate_type and debug_annotate_decl differently. Some would say >>>> doing so would perpetuate the mistake instead of fixing it... >>>> Is my understanding correct? >>> >>> Let us just say that the btf_type_tag attribute applies to pointees. >>> Does this help? >>> >>>> >>>>>>> >>>>>>> Maybe you can also show what dwarf debug_info looks like >>>>>> I am not sure what you mean. This is the .debug_info section as output >>>>>> by readelf -w. I did trim some information not relevant to the discussion >>>>>> such as the DW_TAG_compile_unit DIE, for brevity. >>>>>> >>>>>>> >>>>>>>> >>>>>>>> In the case of BTF, the annotations are recorded in two type kinds recently >>>>>>>> added to the BTF specification: BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG. >>>>>>>> The above example declaration prodcues the following BTF information: >>>>>>>> >>>>>>>> [1] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED >>>>>>>> [2] PTR '(anon)' type_id=3 >>>>>>>> [3] TYPE_TAG 'typetag1' type_id=1 >>>>>>>> [4] DECL_TAG 'decltag1' type_id=6 component_idx=-1 >>>>>>>> [5] DECL_TAG 'decltag2' type_id=6 component_idx=-1 >>>>>>>> [6] VAR 'x' type_id=2, linkage=global >>>>>>>> [7] DATASEC '.bss' size=0 vlen=1 >>>>>>>> type_id=6 offset=0 size=8 (VAR 'x') >>>>>>>> >>>>>>>> >>>>>>> [...]