From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) by sourceware.org (Postfix) with ESMTPS id EE329385626B for ; Fri, 24 Jun 2022 18:01:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EE329385626B Received: from pps.filterd (m0109333.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 25OC9A7E007690; Fri, 24 Jun 2022 11:01:08 -0700 Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2041.outbound.protection.outlook.com [104.47.66.41]) by mx0a-00082601.pphosted.com (PPS) with ESMTPS id 3gvqnc1f29-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 Jun 2022 11:01:08 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TgyyLk/fe7dtF+mDwjphMY62fNtTGKDNzBo3rywO0B29oEdKAR/ZEbzdlKdapw9vxRm+vCmsm70PbMxFVQovNiQyg6T9RvpSZ8G/rLDJQV4FpCwDEkaZcbJfnH9rEgMSVyBXn7ubYhJrY3Q1dtQZfWz0OFZsybEuSq730JThiw2WRcEyw6SNWxqO0y2GNC8TkZH2NZw9srhfWJRBHirkXi5U2IqyAASZMe4xx5qJISKliu+o9zVzN5j7q67cs6m5uZVojcd0sL7O9u8qHGcxQDrRbB0aGhwYnMm52SIN4u/i458zwQlBJwcctSN7s1ewMm08Cz4Jx7nfeLat3tJKQA== 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=3qQ0y2NcDKNM/ouOfBNuJasg0+6wivCaTSHUozVgSiA=; b=Cq46BCEkyqnCQAN6o+chg1SModjHDjRPCVBkZCJlyOTjNuqo+T8BAhsg+bf3yyaZEfj8BX82CSKE+J0h+ZnLIeHsNfCOYsvkGaiNaHJ7Xu26alo5yHmDRSivTvaqAZ/2O4P+K8HSlminWP/Xrtx6De66HdOprq3UtXqJxZM8dIGW3U+9fcLc3YwtVlQ8bQA8eMjxA8nxlcYOT8fQnLkmV7XOIQUkBb+Z09qBvdYvQM5zy9XOJMcjjAgJFLu8tf7OQ2MwVkYVQnwjFdW6/YIEtF2ek9SSumHri/ZmdGLn8l0WW6tGKSf5H+ziOT6gxcrfBt6tFiC7tZLgZoS9NHR3nQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=fb.com; dmarc=pass action=none header.from=fb.com; dkim=pass header.d=fb.com; arc=none Received: from SN6PR1501MB2064.namprd15.prod.outlook.com (2603:10b6:805:d::27) by MWHPR15MB1136.namprd15.prod.outlook.com (2603:10b6:320:30::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5373.16; Fri, 24 Jun 2022 18:01:06 +0000 Received: from SN6PR1501MB2064.namprd15.prod.outlook.com ([fe80::9568:e5d9:b8ab:bb23]) by SN6PR1501MB2064.namprd15.prod.outlook.com ([fe80::9568:e5d9:b8ab:bb23%6]) with mapi id 15.20.5373.015; Fri, 24 Jun 2022 18:01:06 +0000 Message-ID: <0c104e7b-1873-c141-37b9-71444f585793@fb.com> Date: Fri, 24 Jun 2022 11:01:04 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: kernel sparse annotations vs. compiler attributes and debug_annotate_{type, decl} WAS: Re: [PATCH 0/9] Add debug_annotate attributes Content-Language: en-US To: "Jose E. Marchesi" Cc: David Faust , gcc-patches@gcc.gnu.org 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> From: Yonghong Song In-Reply-To: <87edziknc1.fsf@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-ClientProxiedBy: SJ0PR13CA0013.namprd13.prod.outlook.com (2603:10b6:a03:2c0::18) To SN6PR1501MB2064.namprd15.prod.outlook.com (2603:10b6:805:d::27) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4b80238c-db9c-4f4c-b37d-08da560b8277 X-MS-TrafficTypeDiagnostic: MWHPR15MB1136:EE_ X-FB-Source: Internal X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 4INHBi8rDD+hWVK9fpYPMddiC9KuNkRQ1ONcsoSF3WH026GKn4fmUrFrEa7/sqHZlSxDSESyagvnBh/0jnipChxjM9seIWxnszQ5N6fO4yzxhpZcN4GrV8u11+eapeBBI1tcyUXhMjXEAV0tvsYvI3eSPDUQx9v5W9cYv0Fwb/uIzWXevTQxRwKXu4TkTtgY8SqBvLy4ukrrGQwYoW/K6SCbC2TCMJKXc3zMq/bo+sgZP1tXGkdULXe0Vf2aR/skEYOMOfg5iw3H3u/tkBRm+1LdsNQ2H2Oqq+T8tJNTVRB6fvrL0YZbO8AYOohR73UIM+SkQ+ks4yXGllkgRAccXtL7PoD5wkERmBPZxaAmAE8k+ySMgrdvZ8zsyVfgh4zdr3/EPlonT+d9Vj399VOINJXhTVh1dsyXMvMAMKJpxODdLC9e+BEC1aJIGItaibG9loHeLYnPXo5pMCBs3Ma/j3WaVPPL9B0XgDpur9maMArcut/XqoyWceMczcP4WHxPLKZsqw9bTiVuMF9CY8HiwuNaTA5iiheTSxzr1iOiCIpil2HEPnCWcbR6u4ea71/hsJ886vRBzRkRZO7sbFwigzSgpXRStiENPOr9qAfmNiCyY8xCgpIrNPj/9mo2rCv60/3SKj2/LPVirmXtT7EvllAPPnyV4phsw9gLTNtijrmEFMokhNJU0pK8Pa4//7KwPkGMIFSi2Y7Q9Hv+KQ06fJ7SC6issHjp3t0ZbTyOW0mDJs1/9Bx5PSRy3e7rtin20cYDgqbrT/hdFcdKwrQ4DTE7jgy3DbYxEXfq0kOUR6DPCwVele2m1T8/4DHc/Ulp3KBdvVYTQAeLbJF+88zBAwcNqz90+u/4V/0TJ0vcMI/uTB4M6XtJU669wbHMqjd8cAynFpHJJjWspnJ7VPXvoA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR1501MB2064.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(346002)(39860400002)(396003)(136003)(376002)(366004)(83380400001)(8676002)(66556008)(31696002)(5660300002)(86362001)(6486002)(2616005)(4326008)(66946007)(8936002)(66476007)(38100700002)(30864003)(186003)(53546011)(6506007)(316002)(478600001)(966005)(6512007)(41300700001)(6916009)(36756003)(2906002)(31686004)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YTNWa3NqRmhYMVVRZ1hWWVpScU1NWndhVlI5bkgwVGdTWWhaT1ZpbXk0N3BZ?= =?utf-8?B?SjNIc0VlQm9Zb3kzVDhKZ1JlZDV4L2ZhYjJDVXBzVzBlZ1MzQ2N2dnhiR1FL?= =?utf-8?B?cWg5cTFnREZGbXNta0JqNHpJV2VGTmdwQnYydXZpMmNETzBReml4dHlBZVYw?= =?utf-8?B?QlV6QUwrTXJwWTN4Rk9ma3hybnJLTjB4WE9WNU5yOWlNTU9IYXpvWkJINlZp?= =?utf-8?B?MkY3eHZzUmNvTkNHSkpaczRPY3NqaURTOFhKNzNKWjFPb0YrNW9mYk9YR0l0?= =?utf-8?B?T29EaFZjL2VXUmo2cHVpb3d5SmJBTG1mWENUMUJuTDV6SXRuMU5ERk4zR1lt?= =?utf-8?B?QzNTMUxrYnJNVkZZakN0TTE0WHZVWkVGNmpsTFViKzlxR3p4Y0hLOFlQZ3cv?= =?utf-8?B?R3B5Z1hkbGpOcnZpWVdick1LdkRBYTlqR0NCbGxzamZRc0JWdHQ1a3NhQlVn?= =?utf-8?B?Z0gwLzVFNUFWcCtMQUhHUjg3Vkp6c3hDVHVycVRBWWlWZkZmWXREWUVnUDZF?= =?utf-8?B?MVRIckd5YjdXVzVZYUhpU2lqVFlhZTBhN1drTy9FZFdmaVZwVkp5Y3dya0s5?= =?utf-8?B?U29VY3dtS29mejUzUlVaWForbWZsS1dOT1BmcmRlb3dqNk9UWEl2RStxOS9R?= =?utf-8?B?dTc4U0NwR1E0MnY2VmZHbVNIcGZ2dUdDa01PcnhoMFpMR2lNdDNCNzBRKzU5?= =?utf-8?B?UnpHK0VHUjVKMUpyR2l2eGN5Mlhuc0N2WlZhd2pvQWV1dUFjNnB6QkZYZW5X?= =?utf-8?B?M01Wb09JNVhQbTlUcDFOcis0cTRPZ2cxd1k5emo3SXFreG1Wd0c0ZWMrQnNE?= =?utf-8?B?WHIrZGNheFdWV1RKNmhHOGY0WE95bDVXb1NYSXV1M1hrQjBTKzVGOUJqMmdw?= =?utf-8?B?bXdDaTNlSlZ6QmRUTnpuWWVZcEwwTkFsTTR5YVFTWUVmODdhUEhoUFdxQ1dE?= =?utf-8?B?bjVCQzZ3bVFPbWlvSWRyWTVqeHFkNmNCTWg0QjNPWmQ3a2hUZ0ZJeWh0bndq?= =?utf-8?B?WVZIUzBCWW43ZkIvZFhQeGRXRjZuN1lpeU5rZkJhQm9teUxKbUpRR0JLVHMz?= =?utf-8?B?WWw4WGhROUxmM2dFNHdCMnJMc3RMTVIvSk80M3ZtNllBS3oxK1BrUk9TQm5z?= =?utf-8?B?M3hwNDJhRTBoeVYrbTdDZDlXbGJFQ1R2NU5xdm9yY0R4U21CVVowYmQ2cFI0?= =?utf-8?B?WkJsVEFTTC91bjltUWt5WlBiVXJxeUtyTmtBYlV6cVkrbU5GZGc1bWlzb0la?= =?utf-8?B?dlQvWU1nU2pqQXBZN2VkMkEvUmo0bjYyaUFmbm9WaVMrcnRseWZZQndDU0FC?= =?utf-8?B?WlREUW14WXFMK0wrbzJ2eGFTK1VTNHc5RHpvb0Q1a2tYUVJHMEZCZk03NWdu?= =?utf-8?B?VGNPMWQ2dEVBeFNyRkRYL3craCtoVXAwdFpGc0hXak1rNzEyc2lWUjVHY3ds?= =?utf-8?B?UGZqZXRYb0lZa3k1enZFc3M5NGowSXc5d3Q3V2laN2NUWEF0a0JQakw2cmh4?= =?utf-8?B?MDZnT1MraHN1Z3NrSUpPclY5aTFNTXZEMFdrTVVBcG5salNEZjkxa3EydUVQ?= =?utf-8?B?K0xlV1ltazN6T1FqWHlxY1FwZk41RGN5SWorRlB2cjZEWHkxTUUwRFZtd3RJ?= =?utf-8?B?MlJ4dzl1dzl2MHBQZ0FzYmQrRHRIMTdoRTRpMFJtRHZlZDRBdzc2b3dVL2d0?= =?utf-8?B?THFWMVhhR3UvUmxFU0dSSzU4QWh0bVhicjQ1UitmcG5pUWlxVVlyYy9oQVRw?= =?utf-8?B?d1pYWng5dUNnUjVjRXBGWnBJc08yWnRXZ1ZGNnBrOWFnTERpeHJVY0NqWVdz?= =?utf-8?B?amZQUzhJWG1hTEpxN0plUHQrK0pVL0pjZXJCTWo5NkxBQ0c5dUJzbllaSUVu?= =?utf-8?B?eHRsb1F1UUlzMUtISXhTT1FMUTIydlJlREpNTjNOeG5zVXlXMTZUZjlEcnJ6?= =?utf-8?B?UGxzRnIxRXVkNCtjdUV0ZEh0VVVwcGlwek14M3R0YnZrSWpZdExQcTlrQUZ1?= =?utf-8?B?MnlpY3craEJpNXdRUUxyOFFVR2QrSU1tMG5WaHJ5U012eWtPdmZnU1RsY0pM?= =?utf-8?B?aHc0ZmdSdHo3OHhUSDkwaUhkczZQZk1Bc2xJUGI4KzhVc1M1SUF4TjN4VStF?= =?utf-8?B?RFMwNzBCRC9IOEIrb2dJd0xlZmVkei9TV2l3UW9yVE1uVGFiQ3BxZG9zbmFK?= =?utf-8?B?YWc9PQ==?= X-OriginatorOrg: fb.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4b80238c-db9c-4f4c-b37d-08da560b8277 X-MS-Exchange-CrossTenant-AuthSource: SN6PR1501MB2064.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2022 18:01:06.1889 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: GXAV6uZS9zjVX7DqMAk+xqMkpxWXv4LwbahPMIJ0+DOy9Zk0W5dBL4NbvPzxl3xB X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1136 X-Proofpoint-ORIG-GUID: OIJx_djt9_IuWYwD-d0o8Ilgif3UjrCQ X-Proofpoint-GUID: OIJx_djt9_IuWYwD-d0o8Ilgif3UjrCQ Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-06-24_08,2022-06-23_01,2022-06-22_01 X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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: Fri, 24 Jun 2022 18:01:12 -0000 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. > > 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') >>>>>>> >>>>>>> >>>>>> [...]