From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) by sourceware.org (Postfix) with ESMTPS id 08422385020D for ; Mon, 20 Jun 2022 17:07:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 08422385020D Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.17.1.5/8.17.1.5) with ESMTP id 25KFIiZK032174; Mon, 20 Jun 2022 10:07:00 -0700 Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2107.outbound.protection.outlook.com [104.47.58.107]) by m0089730.ppops.net (PPS) with ESMTPS id 3gsa78jdqn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Jun 2022 10:07:00 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OA4d29FpZs5oDM+ERLdff82pMC9hYf4/44dqDRd3own0npQ5uanDqFm9AtfjRmA7TfLTVbLsKeekrGjtezITXGdwhUioNMr4wNoSX/+yxoPSCEMir8ZAXLWraX4AHrjZD6IgeWaFm566iRPrmUWRvJg2xbM/g2+epfGAs0NTS3n5FWKYwh4hfiQgoFoGtAXTOL1tZ3LRKJ9KsldMLBO5QL2aFtFI/T3LEh6u45s6v3LNOkNjTsTtwCFaBzhAFEvzc5snmXYSx6Z/vh/FwvzlCIxUvgtKOdDClRNuzBOnndrKv1M07OxmYfGzA8IVmA0h+LZpJQ8rxkPaQp21RNBdKw== 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=W+qwGZ89GTtFhToH1G0uH1w9XDOym+mYoA3uz/O4DYA=; b=XVEm6Tp12hNeaxkjuoFJcjP1VUjZm+Giki5WmgD6DKlVTj2/2LhvEI8iunt1SN6g0zjMDqevPU/H+CsnrguZ0p0Bu83/HNignPbpF9bGAVBvm2qg87MFgv4HH8RFBof66nyPnbA6FhH6FXilUn7il2y2DfisI5c67n8dwnNljG+DE49v6LIWYMHfAsFrGz8eKb29bv3VZ3p3Ufx7dq0minQiesf59upWMLX0hHzEexUMWl2Iy7sPE9nqqallJVKTN57iEItJ9MmQM8itUN/Na9/hXGXsOtE1S2hceqrdGyumDdLVb8qcsQybo/cNvY+JXO3DwrEIhcTFReXILhFEuA== 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 CH2PR15MB3575.namprd15.prod.outlook.com (2603:10b6:610:2::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.22; Mon, 20 Jun 2022 17:06:57 +0000 Received: from SN6PR1501MB2064.namprd15.prod.outlook.com ([fe80::482a:2ab1:26f8:3268]) by SN6PR1501MB2064.namprd15.prod.outlook.com ([fe80::482a:2ab1:26f8:3268%5]) with mapi id 15.20.5353.021; Mon, 20 Jun 2022 17:06:57 +0000 Message-ID: Date: Mon, 20 Jun 2022 10:06:54 -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> From: Yonghong Song In-Reply-To: <874k0jfbu0.fsf_-_@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-ClientProxiedBy: BN7PR02CA0010.namprd02.prod.outlook.com (2603:10b6:408:20::23) To SN6PR1501MB2064.namprd15.prod.outlook.com (2603:10b6:805:d::27) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 646d415d-92ab-4166-24be-08da52df486c X-MS-TrafficTypeDiagnostic: CH2PR15MB3575:EE_ X-Microsoft-Antispam-PRVS: 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: P7P22oo4cXfuEazhRQDS4Y4arLIRynP2FhTm8xpTkipYX9YUPyrxUTvoZaY0/vX0CP4bDUIkE3hRVVcNV0reX93ubuEko8xjtb6Orde/qqj65yV6UKv0bhkE+WIplypdtKMTjH9DKXRO/Lsn+a1v22meQ20PWmMX/pU7ehGE2xJPkhw4sm5Kol9YDSVON0La2yUFwY10nOEg9nODQ2nr5tDSxBO3Ue3PdWfKA+/tRrSBp0Iasxi1id1S2vAdpzLp5/9sKX8avqZftQ1wRerF+c5XUhHnmN719zSAranfPOyJyjmIpwtxYvAR7EQ7FG+1u1ZRT/5u0nSb/gzcY8mfa7RkLLVUFB4Cq2GQry7y2Ik0MJWt62T6hdrgzfyKAWTmYOSTh/JjpOy+kCVe275fCdFMcEj23SXhCfnEGFGlqc4Y+EE5w/6DfNLwfYgx8l2jrsbwBT9rzw0H5PdmR1vu3mcblNLMkFPSMtmtPiJigAkiObecx7Kv9bFr7hWSFIeWvQaqKvkyCyBJAzLpKB9XSD5sAIKYHir9F/i9IiCmawO5NWH45ubWOIWuZhIzeNw+/Y92+gXkGrwc5+10QGR+N87o833QpVzOVTPO5hR+/BgAkhMsWLU0gwtk1LXU0gfqukKfSPfSxQQC43NpNuuUYMkAucX3CU7XaQsn3jAPJ9tTaId33/R34HLZlwhR5pq4swUh2ASVdcimoe4iFYEkZ2oGZRXfy9xuQHUSN4czQs1qTOK/ARdfX15iO9yib55XQVW7KYtSxJAmET884Fp+GDwwv6pP4GSgCdjU3RGAElvwrUjck7ym4h6ZHxzLAMPSSo1xxtlq78nn/aGuJZlAdHUbHuJt6Z16BtU6r5NX4S4= 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)(366004)(39860400002)(346002)(376002)(136003)(396003)(2616005)(186003)(41300700001)(66946007)(38100700002)(66476007)(6916009)(36756003)(31686004)(66556008)(8676002)(4326008)(316002)(83380400001)(8936002)(478600001)(6512007)(53546011)(31696002)(6666004)(6486002)(30864003)(966005)(2906002)(86362001)(5660300002)(6506007)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aSt1amlZQ0NSSE4xV3UranJrVDlES01WVWozeVNNM1R4WFA1V3A5bVRiZHF4?= =?utf-8?B?YnhJZGkxK3BjaW5zMytzM3FaYlJpTEEyc1h2d3ZBNUJtQUNXMDVzMDRKMlJm?= =?utf-8?B?RUVtdUdPbktJNUNsMTZ3aFZvblptYTIwaVhxR0lDWERNS29zMW1laXd5NlE1?= =?utf-8?B?SEN6emJMTXgwVFJTOWJKYTRMVGVlTE5xQ3dVSGg3cWlVcXk4TXd0ZmRkOVZi?= =?utf-8?B?RkNjdVYrWFpxcmtiYkdUQW13SERtckcxWVVXWitRcDczWEpxMklrYjlqNGdh?= =?utf-8?B?YVJJT3I3MkU2N3VSWm5YYjN1VWJiVXFsY1VJSTc0VjZWK05SMW5jNHpqUzkv?= =?utf-8?B?TjBGMVJTZnZFSE44cStIOHpOdzFPUFhNOXhtZktucjRCYkxBelN3ZnBhK1ZD?= =?utf-8?B?WndLMDg3ck1DeDh5emtoV0J6QWJGWU9NSUNBT2tVU3dONEprSUVwK0FHMHVY?= =?utf-8?B?cXQ3TTNkSnJmVHVHMFdaZzZaNFhXNG1QUVJGUG43d2J1d3h6V05zK3dlck10?= =?utf-8?B?cUpIUnA5aDJiSWZWVlhDeE9hdmgxTXJaVzJtNHl6clBGdkcrWlB2aWxoWE5o?= =?utf-8?B?eUxmdDlQMnZ0Qm5MdGc0cFR1U3MyenVZVTh3bHdmaFMwVGR5UkJLNlM0N3Z2?= =?utf-8?B?OG5aQjJkMFdkMnh1YWtJV2UwS0duNGtYTUJyTXNUT3hiWVZES1AreVYwYlhz?= =?utf-8?B?czY0OEpVRjYwblZqcDRtOFBYRGFoWWJGMDZmZXkwVmFGRDZxcUd2RHVESWxY?= =?utf-8?B?QXR6QTJnaldzeDQ1M2RBZmwwV0ZmeW1EbEsvSFFndXJLVkVLL2duRmJvbXlt?= =?utf-8?B?NXNZcnpCdzNiOW9VMDY4a0hKQlRKWU9qTDE3ZmZ5YVBVUFE5RzJ6anBJUnVC?= =?utf-8?B?K3lRYXQyZGhSVW44STFyL0hCSHhucGVFN24wUlVwZ0s1NFlVODBsV1NCODls?= =?utf-8?B?YUU2OCtzdDJGTURwc1NFWk1KbE9jRWJ0UWZOWEttQnpLeDBja0FlTkRSVEtH?= =?utf-8?B?QkNoRkMyL2w4VkxzOW40SnJnZnRVV1NzblpabzJUSlJWUWxRd1N6UVFGNGpq?= =?utf-8?B?UldkdUlrY0V3OEVUeTA5QnhZT2hKM1VmNUdUS2Y3V2kyNDhEY0Z1clBITjlx?= =?utf-8?B?S1dTUXlTd1k3bER1b1B5cHUzUWJCQWU3aUowOVdmOGFhYXZFOUhLMEtFR3NJ?= =?utf-8?B?N3ZGTzIyNThjZjRsc1FzRDNyTWlSeWhvU3lWblpDYTkvVDJwWEVjWndoaVlD?= =?utf-8?B?bFdCUW81ZVBFWTlEUjQzelhEZ2VMSmgrNmRBSWVRc0hJdTJEVGVFSWFtQUxO?= =?utf-8?B?Q3VsOGF0bFo4WmViU2xxUjBSM00wYkJRUTY0b2RrU1pIM0ZJc1lXQVMvMDNZ?= =?utf-8?B?Q3M3Z09TSk10Q1FwcFR3N3ZaYzBnYU5BVjBmaDNwSisrRVZBTWhzbHVKRXVr?= =?utf-8?B?Uk82RUxYN0dsSHp2cjBXeFVyL2xlY1BYS2l2a3FFMHlsTlZOT1JRM0lpY20y?= =?utf-8?B?N3p1cVRDNk04K1VwaFpXdm1yaUtvUC9uWHNheDN3RkJYUVZXT2hpL1lsRWZa?= =?utf-8?B?WnQvM3JTdXJ1UVNWREI3YWlrbFJZSkZqTk5zaFVaY0xUNXpNdTh1WEZ0UHUy?= =?utf-8?B?MTdjN3M3djRBMFdiRlBubi9CZldXNGt6bnoyWGFGSDNkZG5hVk9FWXpuaE5J?= =?utf-8?B?amF0eDhRYWhhcWdnYkt1UWVGeS9hQWFqY0gyZ0RFZ3FTYW5oZmx1TTQ0M2Fu?= =?utf-8?B?Z0JNV2k2aDZsV0dreURZYUFWMkhTRnE2WmN6TmQ5WTZlWlE1THZmN2JDeGVr?= =?utf-8?B?M3ExL3U0akk4OEpaQWFIa0RxWTQ2RTA4MzhoSVpRaUdvTEI0NUx6MGhGK3Jy?= =?utf-8?B?aUFGV1h0WWY1eGVNQnF2QXVXTldCcGh2cXJDdytwaERIaUFLY3lzRCtkSUZU?= =?utf-8?B?MTJOV01DK0VvdlgvaDZPRERmVTh5eUF4amV2L2FsazhWREdzWjB3WDJMbEJ5?= =?utf-8?B?WGhib0tHaEJFbXNyWHlhSEZzWGo5NTcxZjBVZXZQbnJoaWNMT2NYVlFLN3RN?= =?utf-8?B?TlNad285TCs4RjB3cGRZNnNFTkFZYmVta0ROTU1LYjBZTERxUkVpYWxVWDM5?= =?utf-8?B?SW5IZ1NOMDBXVW5NRUFMYWhzRXNLTmJVaEZ0QXhCMEdFMmVtUEpLQnJGVU04?= =?utf-8?B?S0g5YnhBV3dUYVZneEI4U0lXc01vaGtlZndZWVo0K24xRktiTjc4R2FsRmxI?= =?utf-8?B?QlNFTmZuWnI3ZDk4RXpxYml3N3JUdml4VEt0NnA1blc3SGtGbkpMYzJLVkJ6?= =?utf-8?B?R1ZyZkpjUUxYT0hNckI0NldrZUEwSWRVNDcwUEZNTlZLREhpNDU1T0R4dmFj?= =?utf-8?Q?jrb6FovP/+ZgORO8=3D?= X-OriginatorOrg: fb.com X-MS-Exchange-CrossTenant-Network-Message-Id: 646d415d-92ab-4166-24be-08da52df486c X-MS-Exchange-CrossTenant-AuthSource: SN6PR1501MB2064.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2022 17:06:57.3671 (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: aFYjADDgkRm8j6Q1sefdHz63uJmGJhl1Yo+qxvU+rGfLPwn1Pbi/wa64A8OGcFNF X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR15MB3575 X-Proofpoint-GUID: LnYaxhwnFqiNEB76s_XB-w78cM_ktlMu X-Proofpoint-ORIG-GUID: LnYaxhwnFqiNEB76s_XB-w78cM_ktlMu 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.64.514 definitions=2022-06-20_05,2022-06-17_01,2022-02-23_01 X-Spam-Status: No, score=-4.0 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: Mon, 20 Jun 2022 17:07:03 -0000 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) > > 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. > > 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') >>>>> >>>>> >>>> [...]