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 ED39B3858D20 for ; Wed, 12 Jul 2023 19:33:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ED39B3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=oracle.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=oracle.com Received: from pps.filterd (m0246617.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 36CHOU0Q004409; Wed, 12 Jul 2023 19:33:37 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=message-id : date : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2023-03-30; bh=cQFtyeMIQSIqXM/FbgRaOPYPIgQ0j0/qurW4ZjfSkLQ=; b=s5W0aUZx094ZqBeTsm3wDoePooKBGVEh8x+UZYwSLN9aAjURS36zkTocQkm//9SJwEQz 9Ze14Z5I1XXFxpcW87kqeYvd6rrxziFqDRG5KwI6kIgxA9e1OIx61Kkoq053njcHsnH5 U6YFMAmQqy/mSWYvcUPThJ7cIN4q+lXUgWuW4hIuzH52YJiniZ1jB5Ne0QKppG0k6sVZ UBwX1WQmsUe17nibuY1a9jrdQQc2vDdEn0g+RDmqU5/0F4H2EoFHsk4cv+uKvA7z2x29 gtBDoaONqCrEXJuzMX/HQ7kxULzWNwvB1KLuqRqjR3vYGA76K1p9ITTv7Lkxrw1yJ/nZ /g== Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.appoci.oracle.com [130.35.100.223]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3rr5h16pgm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 12 Jul 2023 19:33:37 +0000 Received: from pps.filterd (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 36CHofgj008367; Wed, 12 Jul 2023 19:33:35 GMT Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2168.outbound.protection.outlook.com [104.47.58.168]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3rpx8dcxwt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 12 Jul 2023 19:33:35 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KbLRIVCcboQVJ14E0coRRzn1FIDZxL39xsBZOL2pP2Fd5Z6KVYTVBiNhZ2kASnUgkUbHzWd3QK0EwAWkGS0X2SNQjlCp86LzgCmi65feF+vE8gnGO582H/TtaeNayx3QnCcIre+5DrB27+RmS0oIg/Pf2mVv0P7DSTSD5Z6Yja5qYc3uWUQdtgTd7fpZ+FzMBwJsd/6Xyyb7lRVdRMoZ+Y2oTqeZ1sERXtE8F6pc1rX1sbQP2tsOyoTYNYfsICg85I53g0bPEOMK/fD4lJ6f6TTXS3O7hWsop6lShcHIv+MJWWK4/px0Ibz3Z+VN4LfqHC1BJIPSFSeoU44KyggddQ== 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=cQFtyeMIQSIqXM/FbgRaOPYPIgQ0j0/qurW4ZjfSkLQ=; b=gh9kyBISBJCESbqALrWWuzzcf4Ov8Q2j73MZHdLJy66Q2QKSJHwBGZtvhrmc/cWjaiqKXRJWx+0liG6hNdQ8Sr+T2ij+r8pkPHGMkp8vTC1tDTZisFh9MZWQ+ugnOwep1m+Y92Kcznoqvg4sro+l2V+i+nusuekhegPnY3lXeGTxj2JZEKWs/B2F474A/eLfz1/MidwUDK/tel1Od55EYScg3fmVV0hL2QGRBA3rY7SPQLRRDmATbgHKWmGfJAUqMAjqTYFTxZOLRHU2BbcOljUrcWb42abuEB4V5bIJmcYDOhm9yWhx396Tuw6fKaRx1jf5sIBEk8yoralDYmVdBg== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cQFtyeMIQSIqXM/FbgRaOPYPIgQ0j0/qurW4ZjfSkLQ=; b=qfwzvynB2q2JhetaCMWxmaWOyL8S3qZafDmZPiXtr2aXBAcfz96UbLzkxngvQXDOLVyjMSyQ78wY3lXqikbcqbDFKfo1/u4MMYpA9lnEPLJw8FCAIhXa2PYyBdrgtRMOvFryhqwF1ZCtku/MdaCqDTb9GlHeMy8RRTG4opi/ZeQ= Received: from MN2PR10MB3213.namprd10.prod.outlook.com (2603:10b6:208:131::33) by PH7PR10MB6507.namprd10.prod.outlook.com (2603:10b6:510:202::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6588.22; Wed, 12 Jul 2023 19:33:33 +0000 Received: from MN2PR10MB3213.namprd10.prod.outlook.com ([fe80::1797:59c3:a40e:f8ab]) by MN2PR10MB3213.namprd10.prod.outlook.com ([fe80::1797:59c3:a40e:f8ab%4]) with mapi id 15.20.6588.017; Wed, 12 Jul 2023 19:33:33 +0000 Message-ID: <53020335-897c-19ad-3c61-5ab4d97bd1f9@oracle.com> Date: Wed, 12 Jul 2023 12:33:29 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [PATCH 0/9] Add btf_decl_tag C attribute Content-Language: en-US To: "Jose E. Marchesi" , Richard Biener Cc: gcc-patches@gcc.gnu.org, yhs@meta.com, Eduard Zingerman References: <20230711215716.12980-1-david.faust@oracle.com> <87y1jlz4e4.fsf@oracle.com> <87r0pdz1dc.fsf@oracle.com> From: David Faust In-Reply-To: <87r0pdz1dc.fsf@oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SJ0PR03CA0138.namprd03.prod.outlook.com (2603:10b6:a03:33c::23) To MN2PR10MB3213.namprd10.prod.outlook.com (2603:10b6:208:131::33) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN2PR10MB3213:EE_|PH7PR10MB6507:EE_ X-MS-Office365-Filtering-Correlation-Id: 8395e371-d49f-46ec-9b33-08db830ee0ea X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: SdvdnFulnfX4h9YvGbx6eXjSVxGfePb7tbb6DtZXHV8bo+pLfftsA6WQLtD4v1/DjCZCBO7/4eOIUCB+o39DXKTK5Ub2BwxcMVwyqo/diIzBU09ruUiG5RcO1lxBUNXsGCYJZXGyu4NfDxmdBkpEkydkHpkSwY6565tfpZBznbNA9ryYoZXqDH/iZnu3HDF2a61NpfbJ2z+f75UyIZfczGDJNCD5c0ri6+mUOM+c1Bx3h3V83dcvPeIlZCiDbtxe+A7pFpiwz4PfWfAnCjVoVFVf6YeW2J8jjDLoQmjvHCgfwWxd7QOdWfqnJL/8j7uBuL+RGg+TmFiYZh0HdF/I+e2ejonH0T4BHMwCkq43s0bnh6QBXVohx5JP/hjgppW2Ds0LWGtUy72OPB8o2QW3B+tLGMlCtcQfjXPlmRICZaxlO5U8SQm5rREXIwl+SAC8aHiOrzA8BqPmjkeYLgwaY7rk9K/Uo8u4b2LjX9dXyVhfRgHGiJd6LGGvJh1LHj3Z6rngehLH4Jdsxw8YU6aqnRigx6i2gBtKLUuaxiRbdtPOsWe2ktN5o98dvuskhGr7EMSxN2x+1XHd5+H6Srs/vZY8KoR2daXVM4nNvDY+rotmo1CKDiHJp3bWO547HH/2i3sZ0CX/ML/CGARgFbK2iQ== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR10MB3213.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230028)(136003)(366004)(346002)(376002)(39860400002)(396003)(451199021)(30864003)(36756003)(2616005)(2906002)(41300700001)(83380400001)(186003)(44832011)(26005)(6506007)(53546011)(5660300002)(8936002)(8676002)(31696002)(110136005)(6486002)(66476007)(66946007)(66556008)(4326008)(6666004)(86362001)(478600001)(38100700002)(31686004)(6512007)(966005)(316002)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TW1FREJMemdjZFNrSmh2SVVjN2kybnJVY3dySEhTZFg5M3lVbzJPVUVuQ2Mv?= =?utf-8?B?MUpMQVRVdmFlb3hLMnpCd205dFQxdGVPaXJSVGppZVdXV3JZcVZOd05zKzda?= =?utf-8?B?RnJNZTRNaHJRaGdWZ1dJZDJ4djJ5VzFPY3ZCbjZlOHM3TEhUWHlhRTBDSjBx?= =?utf-8?B?dkM1bzFtejhGL3FGbHN0VVpHMit2TVo3S2ZvV0JMTm1abDVETVgxNVlQVW1u?= =?utf-8?B?TkRPQWFWbTJsbklrMllZQjRka3ArajdJbTBmOTVmSmlRNWl5ZHlqTWtJUUwz?= =?utf-8?B?VVZOaEhiNGhLWHJENzJrcmVra0hSRFVWWXY3WHVucE1HZXdVVERZQy85VXBK?= =?utf-8?B?a0JRTzFNVnVIcXUxeVdLbW9iR1RmNmNrOGQxODZSdWFrNnVHS1lsNk1oQzFD?= =?utf-8?B?eGNwSE5IOWp3ZzVEczBUNkptekN4OTVIS3RSZ1p2ek94RnZsazIzL3FOdEhr?= =?utf-8?B?dGtvRmU1Q21scmNZUkVDR3Z2TTJxUVFCa2p0M0hSVTlYYUt5WElXbGNFdFBq?= =?utf-8?B?UDg1bUZlRzFUUDNGVFc2dDQ0bGFRaFhJOEFWaGF4eXhjMitCNUNSN2xFTk1X?= =?utf-8?B?Z3k1QlpaZTJRR3ZSY0p2Q3E0bjROQVVDTjdUL1ZCSzZWODRCY2hpQ2FGbGNJ?= =?utf-8?B?RzBYTmt1YnN3ckFBWTNxbHBxT0M2RnRIanlIREY4NVdxVm1xbmNxS1hUWHYy?= =?utf-8?B?WWE0eUFxSnNYSS9OWVJRUEVnVzFjblp1SXVqaEZhay9UcDMwSnhpa2diczV2?= =?utf-8?B?ZTVFak0xbGJjakdoSi9BWDFlSHh3WUZrdnIwOHFCRnpzTnp1WGpMcktEVERY?= =?utf-8?B?QnZRbTZIa2tucGxjYXFDb29rWjFVSFRHVVZuZnl0SFViaDVzckE1eHJtTmFs?= =?utf-8?B?Y3FpVGRiR05XV21CeHI5cEoxaWp4YnBaMFJIbEdxTFN0SjlZVEsyUENGVnFp?= =?utf-8?B?dzBzRmQxV2YvTTZjcEpha1UyZGZKQnVOT1pwZFFVUjFtbE9YNmsybGdaZmQz?= =?utf-8?B?WlJpbHg0ekZQMmJyaDZ6emczQ1EvanBjYmtGZVNLQ1JXVFFmb1JKcVBlTmFU?= =?utf-8?B?VmxIOGRHdzd4SWhOYjFPazZFaTVhTDZuY2tCS1RWUWtMUGxiQ0F4ZUE5ODVv?= =?utf-8?B?ZG9jOEhBMnVtelRWSGkrTlJKV2s0NUxuTENpM0VFZXB0SVJmVWpwd3pDT1Vw?= =?utf-8?B?Rzlsa3hyaUJvcWRFZS9Sell6bWhxWHkxTzB6OWZQYTNCZE0zNzJ5eEE0V0dH?= =?utf-8?B?VEFJSU1OUVZqdGRoWGhBN0VPU3lheVErK3dHOG4wck1UWWhYYkFrdXhlZ2xo?= =?utf-8?B?bm80Y2FlY1VNaG1qT3dLcHIvN2ZHbWRXbFRqaTIzbEhwQ2hVWDZvbDIvbnR5?= =?utf-8?B?S1craVpWY1lNcjlFb0pKSjd5eW5SKzNpL2FRNWZOY0dHMDFiUGtxRFlsbnVU?= =?utf-8?B?YkNXbWhYMWcxRXVQZ3NQZzlvL3NIMlhkYnhrT1BYSnNuZXdoN3cxL3FMRmxv?= =?utf-8?B?UUlaMWprM2szdUxObklscVVjdnFDcVk1eDNkWVlwR2M1aHJuZDNoRFRIQSt6?= =?utf-8?B?bFdiaTcvemlCeVJEZGFqaUI4NVVwSURLMHFyY256c1BRcHpZdFZub21Obm1S?= =?utf-8?B?NmxaMytpNlNzaTBwc3VXZ0tkMzc2eTg0RHlwRUNZNEtXTUoyVmtadEFDazVF?= =?utf-8?B?R2JIaUJYcTFrWEdoaTlBWXIvQVhuZ3pUOUF3Um9ZSmZTbXc2UEJxa1d1Rkk2?= =?utf-8?B?bkp6SDR3Q0IzTHhVakQrbU1xYlBlY1dtbDhUZFJuRi85NTZVNlc2WkIrTG8z?= =?utf-8?B?algzczdZMVZTN3lGZEQzeTVkMXFndW0wY1U1Z0RDTEZyRVV4TmIxa2p2UWxW?= =?utf-8?B?b1liWE1BRlhWbDV0VzAvTUlUczRuREtPUXVUZG5IY3RuRDdiTHRXSElmOU1Z?= =?utf-8?B?b0R0VFJLaVkzcDg0bWNyVmc0alBpMldtekxGVVMzS3JVUkZKTVZLbmF1VmNG?= =?utf-8?B?dzBoR2s5NmZneThLNnByTmNDSG9jdm94RExHS2NHZ0R6dzVoUGp6WG80dStY?= =?utf-8?B?d1Z4RmxnS1lPeTdpQzJ6Q2N3Q1p0ZlY0bHRUbHpMSllKY2JZNzcxZlFkWFVl?= =?utf-8?Q?DuocBVnwDIQl/V0U+qswB/MPm?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: NJTi41+49juabSM4h1FHUpQq7I0OKMmgaFJZdav5vKm/eNZObf/K3ReC3OHtyacdj8kMse4fSO/NauO6ABnXbc2QYWr01N2woyOA2qawXxPFoBm5KPZft5jmdI/fZ6kPzhT5Z41O7/z7hHJfC7ZHx4YqQvD/KK8+jnxOlnLk9hLGt+F/eKpWtsdF8YUmvJkBbOFgcZmPk142+QiZkG+9ni5ZbwJKLyF9dKmRrlbo+ibdpORuMjlw8hc/cZRcIpFa3O0y5IifYaCY8QxaDK1+1Xm0rzahjtNApkdu7+GyEanP0OocL04f2/wJVD2J0KJEsBWpqzeFGS4aBXSqoFEaY86vk5t6Ro6ji4+gr76Bb7YA1W+gcYejj8lzwUqrUR9ceoAwscfW9xq3vpPv0r8UtxepIHhCFcdxoNqe4sT4e0hnKc62gqfAQQTJEiMbtrLHkaZXz5CqOzpCHOgdnR84xaxgE+PQtgZ1GfsxjDWACZaTBUhadXrlx48GCAFjWH82EWF1al5kJm+F6LQfSKO5QHOYTqjtiYUSzdF22kghjPLfUNt8FWLpDB/GDHjWY6mamsVEVF71p7dyLhEZQMWZ2Is29GCyT7kG+pW/9Lquld+f9WWd4NloLQhMJpJfbcW4YQ2TMwbBOEFrxI78i4QZ9MlK7aqCCOIU2ydnkXMRcCuu1IH4etNyNaRcp1o3tWGB9Jx0khyiUVM69TOi6WfUavH9iM38SHTYX4F+RimbLetTdPcS+KexnBw/+xt/8f5vvjWiCGOboVkp1AdfUteTdohHxe0MpFyuFORNa0x9kEk= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8395e371-d49f-46ec-9b33-08db830ee0ea X-MS-Exchange-CrossTenant-AuthSource: MN2PR10MB3213.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jul 2023 19:33:33.1030 (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: M3nJ+k+HlRdIgc/Y4xg0qL3pq82uv+YqwjdyZ+Ua+qCtOEXcxvhNSkEvAL6kGWlIZ6/ranuNgPMaoPJhgK2how== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR10MB6507 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-07-12_14,2023-07-11_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 spamscore=0 mlxlogscore=999 adultscore=0 suspectscore=0 mlxscore=0 malwarescore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2307120174 X-Proofpoint-ORIG-GUID: zeI5m_F4jAWeNhAfp4mjRlfpgp_eo4Wh X-Proofpoint-GUID: zeI5m_F4jAWeNhAfp4mjRlfpgp_eo4Wh X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H5,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 List-Id: On 7/12/23 06:49, Jose E. Marchesi wrote: > >> On Wed, Jul 12, 2023 at 2:44 PM Jose E. Marchesi >> wrote: >>> >>> >>> [Added Eduard Zingerman in CC, who is implementing this same feature in >>> clang/llvm and also the consumer component in the kernel (pahole).] >>> >>> Hi Richard. >>> >>>> On Tue, Jul 11, 2023 at 11:58 PM David Faust via Gcc-patches >>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> This series adds support for a new attribute, "btf_decl_tag" in GCC. >>>>> The same attribute is already supported in clang, and is used by various >>>>> components of the BPF ecosystem. >>>>> >>>>> The purpose of the attribute is to allow to associate (to "tag") >>>>> declarations with arbitrary string annotations, which are emitted into >>>>> debugging information (DWARF and/or BTF) to facilitate post-compilation >>>>> analysis (the motivating use case being the Linux kernel BPF verifier). >>>>> Multiple tags are allowed on the same declaration. >>>>> >>>>> These strings are not interpreted by the compiler, and the attribute >>>>> itself has no effect on generated code, other than to produce additional >>>>> DWARF DIEs and/or BTF records conveying the annotations. >>>>> >>>>> This entails: >>>>> >>>>> - A new C-language-level attribute which allows to associate (to "tag") >>>>> particular declarations with arbitrary strings. >>>>> >>>>> - The conveyance of that information in DWARF in the form of a new DIE, >>>>> DW_TAG_GNU_annotation, with tag number (0x6000) and format matching >>>>> that of the DW_TAG_LLVM_annotation extension supported in LLVM for >>>>> the same purpose. These DIEs are already supported by BPF tooling, >>>>> such as pahole. >>>>> >>>>> - The conveyance of that information in BTF debug info in the form of >>>>> BTF_KIND_DECL_TAG records. These records are already supported by >>>>> LLVM and other tools in the eBPF ecosystem, such as the Linux kernel >>>>> eBPF verifier. >>>>> >>>>> >>>>> Background >>>>> ========== >>>>> >>>>> The purpose of these tags is to convey additional semantic information >>>>> to post-compilation consumers, in particular the Linux kernel eBPF >>>>> verifier. The verifier can make use of that information while analyzing >>>>> a BPF program to aid in determining whether to allow or reject the >>>>> program to be run. More background on these tags can be found in the >>>>> early support for them in the kernel here [1] and [2]. >>>>> >>>>> The "btf_decl_tag" attribute is half the story; the other half is a >>>>> sibling attribute "btf_type_tag" which serves the same purpose but >>>>> applies to types. Support for btf_type_tag will come in a separate >>>>> patch series, since it is impaced by GCC bug 110439 which needs to be >>>>> addressed first. >>>>> >>>>> I submitted an initial version of this work (including btf_type_tag) >>>>> last spring [3], however at the time there were some open questions >>>>> about the behavior of the btf_type_tag attribute and issues with its >>>>> implementation. Since then we have clarified these details and agreed >>>>> to solutions with the BPF community and LLVM BPF folks. >>>>> >>>>> 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) pahole adds additional kernel-specific information into the >>>>> produced BTF based on additional analysis of kernel objects. >>>>> >>>>> b) 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). >>>>> >>>>> >>>>> DWARF Representation >>>>> ==================== >>>>> >>>>> As noted above, btf_decl_tag is represented in DWARF via a new DIE >>>>> DW_TAG_GNU_annotation, with identical format to the LLVM DWARF >>>>> extension DW_TAG_LLVM_annotation serving the same purpose. The DIE has >>>>> the following format: >>>>> >>>>> DW_TAG_GNU_annotation (0x6000) >>>>> DW_AT_name: "btf_decl_tag" >>>>> DW_AT_const_value: >>>>> >>>>> These DIEs are placed in the DWARF tree as children of the DIE for the >>>>> appropriate declaration, and one such DIE is created for each occurrence >>>>> of the btf_decl_tag attribute on a declaration. >>>>> >>>>> For example: >>>>> >>>>> const int * c __attribute__((btf_decl_tag ("__c"), btf_decl_tag ("devicemem"))); >>>>> >>>>> This declaration produces the following DWARF: >>>>> >>>>> <1><1e>: Abbrev Number: 2 (DW_TAG_variable) >>>>> <1f> DW_AT_name : c >>>>> <24> DW_AT_type : <0x49> >>>>> ... >>>>> <2><36>: Abbrev Number: 3 (User TAG value: 0x6000) >>>>> <37> DW_AT_name : (indirect string, offset: 0x4c): btf_decl_tag >>>>> <3b> DW_AT_const_value : (indirect string, offset: 0): devicemem >>>>> <2><3f>: Abbrev Number: 4 (User TAG value: 0x6000) >>>>> <40> DW_AT_name : (indirect string, offset: 0x4c): btf_decl_tag >>>>> <44> DW_AT_const_value : __c >>>>> <2><48>: Abbrev Number: 0 >>>>> <1><49>: Abbrev Number: 5 (DW_TAG_pointer_type) >>>>> ... >>>>> >>>>> The DIEs for btf_decl_tag are placed as children of the DIE for >>>>> variable "c". >>>> >>>> It looks like a bit of overkill, and inefficient as well. Why's the >>>> tags not referenced via the existing DW_AT_description? The DWARF format here (with children DIEs) is the format already in use, supported by the kernel/pahole and emitted by clang. So the simple answer is just to be compatible with the existing tools. That's not to say it couldn't be improved, so long as all the relevant producers/consumers (clang, pahole, whatever else) agree. >>> >>> The DWARF spec ("Entity Descriptions") seems to imply that the >>> DW_AT_description attribute is intended to be used to hold alternative >>> ways to denote the same "debugging information" (object, type, ...), >>> i.e. alternative aliases to refer to the same entity than the >>> DW_AT_name. For example, for a type name='foo' we could have >>> description='aka. long int'. We don't think this is the case of the btf >>> tags, which are more like properties partially characterizing the tagged >>> "debugging information", but couldn't be used as an alias to the name. >>> >>> Also, repurposing the DW_AT_description attribute to hold btf tag >>> information would require to introduce a mini-language and subsequent >>> parsing by the clients: how to denote several tags, how to encode the >>> embedded string contents, etc. You kick the complexity out the door and >>> it comes back in through the window :) >>> >>> Finally, for what we know, the existing attribute may already be used by >>> some language and handled by some debugger the way it is recommended in >>> the spec. That would be incompatible with having btf tags encoded >>> there. >> >> How are the C/C++ standard attributes proposed to be encoded in dwarf? >> I think adding special encoding just for BTF tags looks wrong. > > To my knowledge the impact that existing standard C/C++ attributes may > have in the debug info can already be encoded with the existing DWARF > mechanisms. For example, an attribute that results in some type to be > considered volatile may result in the addition of a DW_TAG_volatile_type > tag in the corresponding DW_AT_type chain. > > But for these "btf tags" attributes, whose impact in debug info (and in > fact only purpose) is to associate an arbitrary string to either a > declared object or a type, we couldn't find any way to convey the > information in DWARF without breaking backwards compatibility, other > than introducing the new DIE tag. > > [What would have been perfect is to be able to chain the > DW_TAG_GNU_annotation in the DW_AT_type chains much like qualifiers are > handled. But that would break every DWARF reader in existence :( I > wish DWARF would have a DW_TAG_type_nop.] > > By the way, as I think Faust has already mentioned in the cover letter, > we (the BPF GCC folk) think the "btf_{type,decl}_tag" C attribute name > is sort of a misnomer, because these attributes are not necessarily > coupled with BTF. Granted, the main usage of this is to convey the > annotations (via DWARF) to pahole so it can be converted to BTF. But > other programs like the drgn debugger have expressed interest to access > the annotations directly from the DWARF, and BTF is not involved at all. > After a (little heated ;P) discussion in the BPF kernel list, the kernel > people said they would be ok with GCC using a different name for the > attributes than clang uses. They can abstract it using a macro in the > kernel sources. My personal favorite would be {type,decl}_annotation. > >> >>>> Iff you want new TAGs why require them as children for each DIE rather >>>> than referencing (and sharing!) them via a DIE reference from a new >>>> attribute? >>> >>> Hmm, thats a very good question. The Linux kernel sources uses both >>> declaration tags and type tags and not sharing the DIEs may result in >>> serious bloating, since the tags are brought in to declarations and type >>> specifiers via macros... I agree this is a good point and could certainly be an improvement to the format. But, I'm not sure how this would work for objects with multiple btf_tags. As I understand, a given attribute can only be supplied once for any given DIE. So if there are multiple tags on one object, it's not clear to me how we would store the references to them. Maybe with some chaining between the btf_tag DIEs... I think a little duplication might be unavoidable but it still could be a big improvement, since the usual use case iiuc is "relatively few distinct tags, but a lot of objects with those tags". FWIW and as some background, there was similar discussion in the llvm list back when the tags were first proposed in this thread: https://lists.llvm.org/pipermail/llvm-dev/2021-June/151009.html which led eventually to the discussion of using multiple DIEs as children instead (later in the same thread): https://lists.llvm.org/pipermail/llvm-dev/2021-June/151256.html >>> >>>> That said, I'd go with DW_AT_description 'btf_decl_tag ("devicemem")'. >>>> >>>> But well ... >>>> >>>> Richard. >>>> >>>>> >>>>> BTF Representation >>>>> ================== >>>>> >>>>> In BTF, BTF_KIND_DECL_TAG records convey the annotations. These records refer >>>>> to the annotated object by BTF type ID, as well as a component index which is >>>>> used for btf_decl_tags placed on struct/union members or function arguments. >>>>> >>>>> For example, the BTF for the above declaration is: >>>>> >>>>> [1] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED >>>>> [2] CONST '(anon)' type_id=1 >>>>> [3] PTR '(anon)' type_id=2 >>>>> [4] DECL_TAG '__c' type_id=6 component_idx=-1 >>>>> [5] DECL_TAG 'devicemem' type_id=6 component_idx=-1 >>>>> [6] VAR 'c' type_id=3, linkage=global >>>>> ... >>>>> >>>>> The BTF format is documented here [4]. >>>>> >>>>> >>>>> References >>>>> ========== >>>>> >>>>> [1] https://lore.kernel.org/bpf/20210914223004.244411-1-yhs@fb.com/ >>>>> [2] https://lore.kernel.org/bpf/20211011040608.3031468-1-yhs@fb.com/ >>>>> [3] https://gcc.gnu.org/pipermail/gcc-patches/2022-May/593936.html >>>>> [4] https://www.kernel.org/doc/Documentation/bpf/btf.rst >>>>> >>>>> >>>>> David Faust (9): >>>>> c-family: add btf_decl_tag attribute >>>>> include: add BTF decl tag defines >>>>> dwarf: create annotation DIEs for decl tags >>>>> dwarf: expose get_die_parent >>>>> ctf: add support to pass through BTF tags >>>>> dwarf2ctf: convert annotation DIEs to CTF types >>>>> btf: create and output BTF_KIND_DECL_TAG types >>>>> testsuite: add tests for BTF decl tags >>>>> doc: document btf_decl_tag attribute >>>>> >>>>> gcc/btfout.cc | 81 ++++++++++++++++++- >>>>> gcc/c-family/c-attribs.cc | 23 ++++++ >>>>> gcc/ctf-int.h | 28 +++++++ >>>>> gcc/ctfc.cc | 10 ++- >>>>> gcc/ctfc.h | 17 +++- >>>>> gcc/doc/extend.texi | 47 +++++++++++ >>>>> gcc/dwarf2ctf.cc | 73 ++++++++++++++++- >>>>> gcc/dwarf2out.cc | 37 ++++++++- >>>>> gcc/dwarf2out.h | 1 + >>>>> .../gcc.dg/debug/btf/btf-decltag-func.c | 21 +++++ >>>>> .../gcc.dg/debug/btf/btf-decltag-sou.c | 33 ++++++++ >>>>> .../gcc.dg/debug/btf/btf-decltag-var.c | 19 +++++ >>>>> .../gcc.dg/debug/dwarf2/annotation-decl-1.c | 9 +++ >>>>> .../gcc.dg/debug/dwarf2/annotation-decl-2.c | 18 +++++ >>>>> .../gcc.dg/debug/dwarf2/annotation-decl-3.c | 17 ++++ >>>>> include/btf.h | 14 +++- >>>>> include/dwarf2.def | 4 + >>>>> 17 files changed, 437 insertions(+), 15 deletions(-) >>>>> create mode 100644 gcc/ctf-int.h >>>>> create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-decltag-func.c >>>>> create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-decltag-sou.c >>>>> create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-decltag-var.c >>>>> create mode 100644 gcc/testsuite/gcc.dg/debug/dwarf2/annotation-decl-1.c >>>>> create mode 100644 gcc/testsuite/gcc.dg/debug/dwarf2/annotation-decl-2.c >>>>> create mode 100644 gcc/testsuite/gcc.dg/debug/dwarf2/annotation-decl-3.c >>>>> >>>>> -- >>>>> 2.40.1 >>>>>