From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by sourceware.org (Postfix) with ESMTPS id 111E53857C50 for ; Tue, 21 Jun 2022 16:12:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 111E53857C50 Received: from pps.filterd (m0246617.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 25LFkfO8009754; Tue, 21 Jun 2022 16:12:28 GMT Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3gs78tx1nu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 Jun 2022 16:12:28 +0000 Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.16.1.2/8.16.1.2) with SMTP id 25LFtwdr027677; Tue, 21 Jun 2022 16:12:26 GMT Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2171.outbound.protection.outlook.com [104.47.55.171]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com with ESMTP id 3gtkfunaau-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 Jun 2022 16:12:26 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oLt/avLk/MPwM8srG/vWVdf8hmUsxzL4QddCskRaD5+Ix8zFY35Dafixyz7PcpWRbuZqVFU8b2LDnCE4A+XEofs1SsJTZkloswwjOVNlu1mgOlJ1xr7S/DaNBMk1OciIYqLSbXb3RebKGbIR9VT2cOPEdA4fMjdZGuKqE485Yg1GWI+8yBrDUhzxeD5HveDrYgAPniArdv5NdpLrvEgGTw2DAygW/UF+u5lJxAZko9Y3wpA02ALVJ4TavIlhfdc1Ftm2PUeBrEam8dPI54oMzL4rEEhR5EMrVSGmXj2bzI0DekMeIdFzJQ7ibQN5VBuMuh4UOEePeHtws8eTewO7fQ== 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=9pem7Pr6Tqu3BHf5UHx2SyC076zE+9zUzReDa9MoX7s=; b=abWRs2oh29JjQ51mWQQPTbqh6r4OqBGWezqP+cKYDvPb6/+jmsqoA/NTOoN++oOw1utLDbC/yjbxEjCde2Xu+TrVmdzfVgtvhwe7OtEM6XDM5qaOI5cUFh8Q7DweehXXRevP/JgKhLMSVlEDjowAHSBFteOj3HLEpibsiOCNT5VK16L/mzOrxGTnbJh3KoG+Bp8TrizkFct9hrPftThPzDdP5MfB9aqlTMW9D3H50QJjnvRgsfVX1nIgTlHAJnQxKwz7VPWmyXyivmV23zxKJ3TFCPLBVAHz/Tc6Tn39Q6wTMGlgaBPeIJiDTuZkCJrCbn5gYLE0iVT4I767eYxV0g== 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 CH2PR10MB3943.namprd10.prod.outlook.com (2603:10b6:610:c::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.19; Tue, 21 Jun 2022 16:12:22 +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.5353.022; Tue, 21 Jun 2022 16:12:22 +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> Date: Tue, 21 Jun 2022 18:12:14 +0200 In-Reply-To: (Yonghong Song's message of "Mon, 20 Jun 2022 10:06:54 -0700") Message-ID: <87edziknc1.fsf@oracle.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Content-Type: text/plain X-ClientProxiedBy: LO2P265CA0366.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a3::18) 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: f4aac762-5404-47b4-0044-08da53a0d290 X-MS-TrafficTypeDiagnostic: CH2PR10MB3943:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3sHXTtBsiwb+p0bKTuhh8OMnQt4Y/WA4yyOvY+DoaJG27JXv7t1Mkqy3dvspiKtAu4tX3/KMGCBwRfmzKWILCr1iT8695tqz95UD9JFff7XysM3Jz/0rbjgohFnTexVEUZFaLLNy+D/+rYxkhm1tbkBD7Upwmpp40ZK6T1ymz5Mfzw9IJcycLN7/bJUrdU4ADCd8wlWnrv4503pNJ75dsPUII5Onw5zqnsscQ+uDNZh28o6RhyIb+O0zV+5IcZnpWbwHPzHxmh0ZXBoUGeJNJh8xFZTpCIcgTIbhBykNKhSOvReRr6UAkrxY/nPRS9ZyBvxhAV489QAnEJNRS8TjEGNh5Y/HUh7bGDZhetUo+ZtGCRJ6v1sVi2oa8TcCQDjdCDedZJCi1DIqkObod7N0invTT8Ym03hHGwPwC83sYgU738kB0kydmN8LqH2x2iF7o+QHcCdqy1aJ8sigqzxVqR31x1Tft2fIewdB89yjLGuuot72yQ+4k8p4TmsrhfDOITIWskq0TWkRQ+HJns3eUe5IK/3qKt7aQPDm4T2IZksVp7K6nnhBQuprUWSEWXLp08Z9LEUoBXZFuJI+hpTeCCmaIt5JbVWoTUaPVpWbfvhG2lL/BkZ0X5czM7+fUvNbV8QO//msVLduqhi6bwhA4Qhw0j/yRX/cXXnLAgq9jukxgXy7QWq+LO6PurZX97L59/gDMbWznnloFbhCsvIhwieLSLLvxKW6FSxZIHZUkrL+B9ClqPZ5azovSK2u0dFgNfj8owgQSJHp99G6gMCpiBolSDYmbNkFv+UPidwrZLS6lWZ03G6wl0FmDFHSeKeYdubqMGLzQwpU3jftW4Dohw== 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)(396003)(366004)(136003)(376002)(39860400002)(346002)(2906002)(38100700002)(38350700002)(86362001)(30864003)(52116002)(5660300002)(8676002)(36756003)(53546011)(4326008)(2616005)(6666004)(66556008)(966005)(66946007)(6512007)(6916009)(316002)(6486002)(8936002)(41300700001)(83380400001)(26005)(66476007)(6506007)(478600001)(186003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?EqxIOyLZ2otuKYa4W831R8/7eSv3t1x7xuuZvC2YDYemw34T3+AZV8JAqUr7?= =?us-ascii?Q?Izbbo/cl12hV9xvMoAO8MmezcfArJInRBbgLMVMMJUdZpFzYOhm5wJO3K2hn?= =?us-ascii?Q?UcU1y6jKGtqz+cFGHXCNrO6XkKZPtmBRPu9haSU5nPH1otRpsP3Qy4y8xCTW?= =?us-ascii?Q?ZYKQbi7wjF3T854v3+ICEl0xM4+SOwyB/b6Sgd50V6q6MFucFZt0P/SsZaTC?= =?us-ascii?Q?/iHGBy2v4ZqEMf7vAB6uMufb/MmVtTGuyVKzunm5W+YHOqq97vZSaurFslD1?= =?us-ascii?Q?wmGNzj5XlOrb1ckmZp8c7bf9Ovm9n/Gx1Hb9o0mL6S+puZfFm21Wn293ywq0?= =?us-ascii?Q?J41xckWGJMfLn8TzEXm2kE5TMkkIBUmRHR0CLKtTL9en8uSw5lO+Uf0mpjT/?= =?us-ascii?Q?lFkWFgoq0Y2XsjgMkDfeuZ8IMew+2LprVzXR5KwmFz0bNj4mzxknNSoBtX6Q?= =?us-ascii?Q?nPivx+wjz61qvqtGcbjLyz0dIJ+/w81uXtY9x3BOrPwyhvyHt74mooSic7RW?= =?us-ascii?Q?3SPXFioUcpMlDof8MS/4lY8Vmj7uUzZ+vaH6t9OzomnRhuj8PpmeVi6Nj+E8?= =?us-ascii?Q?YxD1s/p1SHe20OWnoQAMRI8tdNVsX8OmB1GdkmqbtBtieVZVYZvjlBPR3btW?= =?us-ascii?Q?MZ1SJB6FyHEigqlWpfJiSUr1kSy8nZ/PJwRQ4WDrVdD0F2Daxwy4H5W+hR0/?= =?us-ascii?Q?AtFFKtCut07/a8/PfQm/QQHGW9HcsaSZ7wwEKY8E6/y6tLZpIqVVZ/s7FGGm?= =?us-ascii?Q?gIxjRY5rSUjrR5Kezncf3CFDDcLVgWQDFaQXEYfNj3dHMo6t46OfPcztf85G?= =?us-ascii?Q?JKjKtx2/nzGJQZOJmJKLwaO9ML2lKOK0zDKRbKe0+0JaGizLeJ9gasmu8CXw?= =?us-ascii?Q?Rzyf/NcoPcIvd3MWEDYAXZNNJYboLPn0WY2wsGMINTc12STs7DwKEksGTCAY?= =?us-ascii?Q?JIs66uOhMLNJ7pCMWakKoYHbz/TSQw1j64HytXzR4GYZmO836lARh23LR4on?= =?us-ascii?Q?NuJ/b6/WR7z+iXeJzf3scjEVCA+xwtT5DqzDbQ7sC2L7oh8KeO9abE1tUc3X?= =?us-ascii?Q?tu+03h2V+TfsVQ8XCWcgHwoV4keElVz4kSYNSVdecJDEqZKuqr6Lp6TDoDkp?= =?us-ascii?Q?CrbO5XgRjIrqaUm+t5HbdJfoArDuSVYCZttaQRpcxm7lrBP7+dV3nIl4IIbw?= =?us-ascii?Q?WjjHum/qegLvf3SIdrxERektU43ry2gc49lU/bygYZjh4rp9Gekn0Dyr/CfJ?= =?us-ascii?Q?wCumPWr533etjj4dML/VcB+/L3IWq7JKT/xlynPKmHqH9jtnk70FKYLGGaah?= =?us-ascii?Q?TMAnf2WtfcLH3a956dFKIiDbVSrLV93KD/MummEdQhDJ4Gsd0vrBqK0JJkdY?= =?us-ascii?Q?6hHSLzJlS/OShJ4RWcl9JjJ7WBNpt9xhmhmVSidESRqRzuuCR+Sb4Gbmurj+?= =?us-ascii?Q?WDyIIBuTqniAaHn5PYje76kr5CHpKk5+CiVRPvG/qR9YAV6U0xAGN7Syqgpr?= =?us-ascii?Q?SpH65oBxVg4X7+DVw5fjy/6UpjV+oMcyjY1pY4guY7AM10S+iUgVEkmcgKU1?= =?us-ascii?Q?3xKbjrcnxOtsKjGvrMc6k2/NJWlSRE4nnoxPPXDt7uosVRWfF+5YtC5C3Zpg?= =?us-ascii?Q?JP43VT7bEN3HZlH9kVq6aFADERNCMRvAbLqZWWE8DAJiDdRQ3yQu0aqcVjdO?= =?us-ascii?Q?ULkpr8Bz9Ik7gawq6DvwW3DJrlo0MC4SojaNiOo35JVhSMu1BVx0otCIr/Mg?= =?us-ascii?Q?qaJQnfLrB0phmGKe1yAfq1Ame4FFrHQ=3D?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: f4aac762-5404-47b4-0044-08da53a0d290 X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB2888.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2022 16:12:22.1371 (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: X9vO7x0e0s0fvuLwmHTsJLa5tzqZWiGz7fWj1wWMC1I/uCQF5/x7wZWhWhuex2uyJI5I+MPTf1xDduyqQ8PUePXZomu8YDUMzJvUitvw4bQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR10MB3943 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517, 18.0.883 definitions=2022-06-21_08:2022-06-21, 2022-06-21 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 mlxlogscore=999 suspectscore=0 adultscore=0 phishscore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000 definitions=main-2206210067 X-Proofpoint-GUID: bttxVcMKKPu_y47dAgwLI-cNhcgJgg1f X-Proofpoint-ORIG-GUID: bttxVcMKKPu_y47dAgwLI-cNhcgJgg1f X-Spam-Status: No, score=-6.0 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: Tue, 21 Jun 2022 16:12:34 -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) 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... 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') >>>>>> >>>>>> >>>>> [...]