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 7A23E3857702 for ; Wed, 12 Jul 2023 13:49:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7A23E3857702 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 36C6D1Sq015157; Wed, 12 Jul 2023 13:49:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : in-reply-to : references : date : message-id : content-type : content-transfer-encoding : mime-version; s=corp-2023-03-30; bh=N0e9/Mi/xI9EUfwq3AXXzpyM9lD7dXLnQanuU5M7VW8=; b=p0ln9y8V6HHEYADEB8qhc0KY8GJK+6AnJjkTo9W96TYx1TAxggZw+ZjOyJ2dnVmrLaqp Xdhatpuwr6kh+QMMYIaxpfhHM3LEd4U08P+t5/R5qVPd+nPW8NXFC4inwZVFMc+br6+T se/9KM/Fok9egjLhaTILZ0/4HxtC2Bb0k6/W+mqIOMDCroR9zHCYpH/oaVaecTlXlqIf zs3KaXFHoXzD4naxe18/PYQL2cPR8VvN0S8u/e0gdB1zTx8q27fCK0eVW90skHVpOkC7 UrUyQvuD8cDOuGTqBnYuDez5hkdvb5nwqVc3DFSXr1icMNAK/2073F3tSaqOkVnHDOYv yQ== Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta03.appoci.oracle.com [130.35.103.27]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3rr5h15wb2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 12 Jul 2023 13:49:15 +0000 Received: from pps.filterd (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 36CDUUvu000694; Wed, 12 Jul 2023 13:49:14 GMT Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2100.outbound.protection.outlook.com [104.47.58.100]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3rqd2av8vh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 12 Jul 2023 13:49:14 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nxptYQs/UDhPvgx+RzKaRRtZG+lPeOHeugU4/feQt8+RzDO4SALYT8nYHs8HtgMz7/nMd+DEq4n34u4MS4p5s7NAmAqOtqgrlpYv9huxoOSpDQ6R1p5SdgITcDdve+QOfISezOUQXqQinSrpRBLG1L3WpsXigniReuiSr8xxsx3kjaWpLZzWTVUIWRQkiIjRcPsDk7N4hvJ2xWg+kYqIkbeeXh8oPMlWoKU46fKEwOQVmDCbJBZ/Qw4Ia8+/J29GvN3MmdZsee+wFUFbwIbK77XcPty8sMBOs8MpytTd9FEnjOgG8SD6OlM3bHBrxvoW2ydGxEqFoQf1vejIjxxp6g== 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=N0e9/Mi/xI9EUfwq3AXXzpyM9lD7dXLnQanuU5M7VW8=; b=B2TW45plQUkwXL6+pqY8vBsgnMD10905evd5ix/eoDT0J0FqpsvzelgILr9cZoJWq0RR58wxYOfY2WOwYtCAOpYXU2tRjIwXGD4m7QAjPvFpTVPmOdKJtTUhq/V7IZsJJfgakJemGZUsnzZ8f0KF7WRJA7ea6mszUrA2u5X5bybKO9OwyFP93MPkARYleXpP7omwtyJa4THkcZ8blbE+nuh0XGT72+pOS7Hu4xDqOioph/asfowq+D8kefgcYHnc7ao2PAxWzZhIBDvfpUWVO/4tmWo1WNETukUPdUQyAeqVBZOeKFpdYsca8lzCnsNNqlib8NwetowIlvq8QzT4Vg== 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=N0e9/Mi/xI9EUfwq3AXXzpyM9lD7dXLnQanuU5M7VW8=; b=Hk2B356P9kz7pPbRVfDhpEXbNbt8RonWTwUl05RWkJZ9XJs0eBM5rmO17W1aR+bGjizaIX+uWX6KZMBkGep8DFRH196eNufIhTUFAU4hzmjvcpn3piFkIei5sBAINZLo+Li3y17BNpN8rrRsuZBpQAOJLTtxiKji7p7KRLACj8c= Received: from BYAPR10MB2888.namprd10.prod.outlook.com (2603:10b6:a03:88::32) by BLAPR10MB5330.namprd10.prod.outlook.com (2603:10b6:208:333::8) 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 13:49:09 +0000 Received: from BYAPR10MB2888.namprd10.prod.outlook.com ([fe80::b2d:6b7e:39d:eba8]) by BYAPR10MB2888.namprd10.prod.outlook.com ([fe80::b2d:6b7e:39d:eba8%6]) with mapi id 15.20.6565.034; Wed, 12 Jul 2023 13:49:09 +0000 From: "Jose E. Marchesi" To: Richard Biener Cc: David Faust , gcc-patches@gcc.gnu.org, yhs@meta.com, Eduard Zingerman Subject: Re: [PATCH 0/9] Add btf_decl_tag C attribute In-Reply-To: (Richard Biener's message of "Wed, 12 Jul 2023 15:21:14 +0200") References: <20230711215716.12980-1-david.faust@oracle.com> <87y1jlz4e4.fsf@oracle.com> Date: Wed, 12 Jul 2023 15:49:03 +0200 Message-ID: <87r0pdz1dc.fsf@oracle.com> User-Agent: Gnus/5.13 (Gnus v5.13) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: LO4P123CA0224.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a6::13) To BYAPR10MB2888.namprd10.prod.outlook.com (2603:10b6:a03:88::32) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BYAPR10MB2888:EE_|BLAPR10MB5330:EE_ X-MS-Office365-Filtering-Correlation-Id: 0695cb7b-92aa-4c8b-fe61-08db82dec41a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: vQM8UTIBgPtuU/F6AyURvH8H9x1sMZrSrU3KeHz496NiOom3yZvDZrIlQrKuq15J5osSH2klWqO494hCCG/K0Q8KgMj65xnVts2NBilliExVCbKisDOi6CwyHsQfq4Dd2OMVKpvG9D9v1+ox1Gu8NmA0NBWFuThclBeKYXBULi6tWCw79ty8nFFYB/tQUwVY/OiTAFb14dRrCIqDV/mEXR91DjwGsDp5fVdPbS1WR0D9oJ5Vxr31+8hO1l9Cg5Rv+oGWIL6KP1b/oxjWqbyC/XdZa7cvXQydiHrMEkmaxiPzgVjwY1wUD0iP1wxMCAw0bMkywC78TqH4Kd1GS/TCce4MaImmgolMWeFUmRDnZ4YaHHDhRtSE3JDu1pYEFxbCqJ2NrHxhhRB8kOOZC2PdTqEn3i2EtcNKqX7Dw4ZoDIsuTijDLQk7AfCVyKUgtI+JSWa5Gg+sUpFNxaZ6rkUYM4vlAdjer3c8QpQrLrIUVxVTNTOmPSHTcy74MVNgfA9PmxS1eZDwg/+BNHIbQMrFpGEsGLhgGVse19w+Py2ekQbd2Bndvdd4FKGmrppFZ4BLYvkz5YnqweFbCIHwS8PKMQ== 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:(13230028)(346002)(366004)(376002)(136003)(396003)(39860400002)(451199021)(6486002)(966005)(6512007)(6666004)(186003)(6506007)(26005)(53546011)(83380400001)(36756003)(2616005)(86362001)(38100700002)(4326008)(6916009)(66556008)(66476007)(66946007)(30864003)(2906002)(41300700001)(316002)(8676002)(8936002)(54906003)(5660300002)(478600001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RmMxRW5WMzZ6UHFoTVlyVU1WNVh6dzJwT21QNzlzeURuR0tVQlV0UmlvUmdu?= =?utf-8?B?aHV5YTlKM29RWS9XYU1pWUxpNHhnK0Rlck1YT1VaZ1dNa0kvYk9ZS2hYbENy?= =?utf-8?B?S0Q1a0xhbWhYZzJWSCthTmdpSDVJczl1MGswSVpQcUZKb1dkRVdQbi9lUXNX?= =?utf-8?B?bnRRZEcvdFFjT2pJTE95UHZjYzdlMnhGRTRZaTlRRXFvOVk3V0JscnpZZUxr?= =?utf-8?B?MG1aK2IwS3RWQWFuQWc2ZWFvV3pqT2djNW1CNDNsRDRLbE1PMlRzSDI3WmpT?= =?utf-8?B?QTkxTmxoTmFHd2lsRkloL3ZBbGRwNC8zdjArNnlQbkwxcVpRRTdwdVRINWlG?= =?utf-8?B?ZXc0amJzRUZmdGJUWGFyL3ZkMG1xNFlXVlRKcVVWUTBUdUtTb3l2d1hyMkp4?= =?utf-8?B?UExRVE1JdzBldS8vQ1JEdHdDZUk3S29TaXlEc1FHeXhidUNZajJoaHpaNmNN?= =?utf-8?B?WUlzRGlxVzhTTHBESjh0UVpJRHlhaUE4aTVkdjNNNjVFUnBXblUrVzVXNUVz?= =?utf-8?B?Slp2WkpQUlVTT0s0OVBoM0lYNW84YWhTSUZ2TVIzVDBGTDRsUXhtV0xpTVVH?= =?utf-8?B?ZXF5anBIb2tsbkpvQWh2cm9EYkdIekJsWmV3eDFkU2k5MTNoMkROclV3bjY2?= =?utf-8?B?aVdVUWRKL0JuTXREUHFoTUlSWHFIZkF3bjQ3eGJndU1ITExIZ0x1d3NTbE1v?= =?utf-8?B?a1d0OTErSGdnK1k4ZVo2cWx6S1FVc3RvZGJYYmZwS0xBYnRQSDJ6aWlTc0M3?= =?utf-8?B?ckdOb0JoYU5PcjJia2hiQXlxYjU2Rk1sZnd6TllwVXNxWWIwVlA1T1RvOWV6?= =?utf-8?B?dmhnN00vSkVUL3VpdGhCOXNvdXZwTUJlK25LWTlIMVA1ejUxZXRKUFZBL1BV?= =?utf-8?B?bUR0aTF1UWpXWjVlM3QzR0pZQkU1SHRJRmx6dmdJRXM5MWIxdElubDZjOG5D?= =?utf-8?B?L0hrclR6Tll3ZUo3UFl0OW52dXVVbUxHeHMweXg1ZW5jSjFOUm0rK1ZtUnln?= =?utf-8?B?M3ZnUUNaWVlLQ1JmRllyWlRXMGVxUHdsVDdNdi9CbzhvYXE0VkZqNXl1NElH?= =?utf-8?B?ZVNRaFpFY0lDZHJpcFY0SE1mUEZHdGxLMVE1cDVONFBTR24zOGJndGJGZkE2?= =?utf-8?B?cENzMGZYSTZFeXVqb3BTaEltcCszTkdaOGNaeVhwU20vTm9NalBQSEF6MndN?= =?utf-8?B?cW1EQkxtblZrR0xUcWpQLzByT3oxd2RqRzF2M2dnVkZEaUk5QnVRcDVadXdp?= =?utf-8?B?UVZ0clBEK1ZpbUswcDZZN0pycUtlQ1ZtYWd6TWx2ejU0SmgwcG5uUUFoazFR?= =?utf-8?B?blB0Mndnc2Z5ejVneFBvakpCR3l3b1ZyMnR4N1hPMUhTRGNtaUZRTEtEalJk?= =?utf-8?B?YzZoRHNVV1BZK0d4VDhoR2p3STNjSHVGOVlRMHQ3dWVoNWx5UlUzQW13NGVw?= =?utf-8?B?T1dPaWR0Wkp5ajJpWWMxR0poeVpabUIwVzJtR0M1OHZWcVl2R21HcU5MdHl1?= =?utf-8?B?bElwNkVwV01RdlVtSm56NTBheTZXSCtxYk1kVkpBZ1dzUi9IbUp1Z1dNQ2xX?= =?utf-8?B?YTNjQmt3bWFWQmY4U1Z3QmtMVmIwMVMwc0psWTdpOTR2bHBHYW5pOFB2MmZ0?= =?utf-8?B?d3NaZHF4L2RaQUVqL3RjVnM3QjlsVzhCQkVxbnkwbC9PSVdXNWl1YURmUUhW?= =?utf-8?B?TTZ2MGQ1RGtEaVV5dTM2eGRNRGdKTFpqWlB5RCtNZWFZelM1UEhNSFdCSldV?= =?utf-8?B?NUdXNC9kNVpJZzArcXpHTW5KcFFMMkRidktSMWdtUE9FRlZtYno3ZGJjcktk?= =?utf-8?B?UklMVnU0WG5HZVlXYnFjaFBnbFU5eW5JK1BSMlVWRW1QM2tSNVZJNnY1QVNt?= =?utf-8?B?cFlsUTdnd0tIUXc2MXhIcmFEUjArYVhEWER5UVdTY1h2RzE5aUdPbWRqaXdB?= =?utf-8?B?bmlvMmpIdXRtb2ZMVHcxREVEaU9RR0lCeHRQZVlxTGxDbXNyUk1QS2NZRjFn?= =?utf-8?B?K3gvZkxEbnZlWXlSNlBvYkw5dWRpcnpoTXdaUW5ibjY1Uk0wZkVQYXZPcm55?= =?utf-8?B?cCtCMllWTXBZaTZNSGlxdXhCczZPd2cyay92TEZLV0hRTHRIb0Exczh1WVZJ?= =?utf-8?B?UlFnaVpHQWl4NWZESDNkTzJxQkQ3M0F4R2NWWDQycGN3d00vNEczSGx4ZUNS?= =?utf-8?B?Tnc9PQ==?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 7D6mpQQc6Xh2YGTKLTPfZEYNJLDV3KNfhXqkpfu/DqYjWGeTkxdvb/m4VyYYNxuPoAGmU1im8TOY86biWHF0oHXWKBKIRIT62624QmHeAejiS7AGHsVkoN8iPLcUc3YGKEk8oZettju04Kc4dkrB3tUkOc+D28tq4EClzMmMC3X/DATgssn4ShNqPyZldD5wJ4LkwHPM1KmUbiEjFANCWMRZ+SJp/UyKW3rqD7gr/6sdRpB+Ri+OPxxKCy3HnQ32OPNDXZLd/wNILJeY1PGqJuPq3/rvh4nuV+N4Wfk7Wid8H51ps47Rao4T1EZsdvjQNy43zVXRUDJ4c/5u2Sh8JiTR9UasSJauUIXLwsQ9W9ymm2ozLHsBKz0WzT8uEcB1SSa/dmt2pILooWdI9TZ+X6V8v6npI8YykyVR6yZTcGw34TfKzK7DYmIAP7/OxM5Wb5U2HrRqvUkXhbKDi/8M7KpFN+fMSX9FRVI2YSgKmTWENC/HmHt1UMWby0CRyWOFsNorB0cIqkeyJvyA/uLawqYQufa3g49UHT6Z4UOJAul+o1xM+2fQHbCBFNzTfQF7NMcrbwOqqociiztfGDuEshsiR5xUw4zFK4+snFh/Q+RuaER5U/VCqKgVtLnUIsiijVWzD3jwOMyQE+V4af+eV3q2fNSwRD1LSU6OpdDF0/9LnnPxwfSV0mmCCbwMjlfStztZjUkHMAm5GOhBkJrRLzq8KlpIbvtPmy/47RAA20LU+aph8ayQmFX+zlCI0jSXGwPQduLDXxo+cI8VA6GFmlbPvvvgO5ulDIPt8EukS+w= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0695cb7b-92aa-4c8b-fe61-08db82dec41a X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB2888.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jul 2023 13:49:08.9992 (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: BvAwA8Sw2kr/2EIARJQOwkZEc4/J40x1DBcwfPDis3u/0iNZ5IYI4g+qksuth5B8CNhGA9LWlGecI3i/JVvSug7vcvkT4o6/0+j60DxPrlg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR10MB5330 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_08,2023-07-11_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=999 adultscore=0 mlxscore=0 suspectscore=0 phishscore=0 bulkscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2307120124 X-Proofpoint-ORIG-GUID: NKRoGQMgD1gbDscBbUiOfUp1ac6Qktc7 X-Proofpoint-GUID: NKRoGQMgD1gbDscBbUiOfUp1ac6Qktc7 X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,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 Wed, Jul 12, 2023 at 2:44=E2=80=AFPM 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=E2=80=AFPM 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 vari= ous >> >> 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 int= o >> >> debugging information (DWARF and/or BTF) to facilitate post-compilati= on >> >> 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 additio= nal >> >> 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 DI= E, >> >> 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 kerne= l >> >> eBPF verifier. >> >> >> >> >> >> Background >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> >> The purpose of these tags is to convey additional semantic informatio= n >> >> to post-compilation consumers, in particular the Linux kernel eBPF >> >> verifier. The verifier can make use of that information while analyzi= ng >> >> 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 sou= rce: >> >> >> >> +--------+ 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 transla= ted >> >> to BTF by pahole) and those of the BPF program (available directly in= BTF). >> >> >> >> >> >> DWARF Representation >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> >> 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 ha= s >> >> 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 th= e >> >> appropriate declaration, and one such DIE is created for each occurre= nce >> >> of the btf_decl_tag attribute on a declaration. >> >> >> >> For example: >> >> >> >> const int * c __attribute__((btf_decl_tag ("__c"), btf_decl_tag ("d= evicemem"))); >> >> >> >> 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_d= ecl_tag >> >> <3b> DW_AT_const_value : (indirect string, offset: 0): deviceme= m >> >> <2><3f>: Abbrev Number: 4 (User TAG value: 0x6000) >> >> <40> DW_AT_name : (indirect string, offset: 0x4c): btf_d= ecl_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 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=3D'foo' we could have >> description=3D'aka. long int'. We don't think this is the case of the b= tf >> 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... >> >> > That said, I'd go with DW_AT_description 'btf_decl_tag ("devicemem")'. >> > >> > But well ... >> > >> > Richard. >> > >> >> >> >> BTF Representation >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> >> In BTF, BTF_KIND_DECL_TAG records convey the annotations. These recor= ds 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 arg= uments. >> >> >> >> For example, the BTF for the above declaration is: >> >> >> >> [1] INT 'int' size=3D4 bits_offset=3D0 nr_bits=3D32 encoding=3DSIGN= ED >> >> [2] CONST '(anon)' type_id=3D1 >> >> [3] PTR '(anon)' type_id=3D2 >> >> [4] DECL_TAG '__c' type_id=3D6 component_idx=3D-1 >> >> [5] DECL_TAG 'devicemem' type_id=3D6 component_idx=3D-1 >> >> [6] VAR 'c' type_id=3D3, linkage=3Dglobal >> >> ... >> >> >> >> The BTF format is documented here [4]. >> >> >> >> >> >> References >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> >> [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 >> >>