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 BFDE73858C1F for ; Wed, 12 Jul 2023 12:44:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BFDE73858C1F 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 (m0246627.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 36C6fkFT010886; Wed, 12 Jul 2023 12:43:59 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=2id8ByGn4Ivy9z5GM670WdybfgtbuzVd2aEqioHDomU=; b=ruNPnKpLEcvJWWzFWNu9YEdyfFldKfSjHYobQNhlND42aJ5mDKJhOUqAMbrwZsqvWGj/ H6hVScQlx7+0geglsxkOehW1x4bF1T3OKi4hDk7wXrN/O503EEKfoN0SFF9A0xvmB4Xw 8Kp8CCWjRJMie8GOZTxQAphLUXf/qsbvt7JOGDq8VDRY7LWRsva7fONlOmc8WgOQUzfX Bbw7iHC6JJUpb/ujy6XD6bcznoJP4uR4t20aVGUk3VC34yVNHzVZWt2/Kx3uWlSL7SHC y4Sm2XISH/Vbgsv3yV7SGVXu6qhftjvIQoRunYoLLvjQq4EJHYL09WfELe7lX2VWgOnx FQ== Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta03.appoci.oracle.com [138.1.37.129]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3rrfj652hy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 12 Jul 2023 12:43:58 +0000 Received: from pps.filterd (phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 36CC1umF033252; Wed, 12 Jul 2023 12:43:58 GMT Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2168.outbound.protection.outlook.com [104.47.58.168]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 3rpx870hvh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 12 Jul 2023 12:43:58 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Oa4VxetHiakNTFBZfMUBVzYXYxl73gysyTyZNnpH7LTdyXPco100QaEpnDLB6rUVtz5oEzANeeEZ6zCUgvSNzAojsX+7WbotI+Kzz7yiR3sahyxki0tIUwNTGKNAzQDpuamOrHIY5U/B3rXBcbGffVL3pBQrqjdggmW2EilQLCbvP12SyefNN1xM69c3cuD4fyBHn0jEw450N+uapXDEFukuA0hX/iz2UnwM4Gw7JizfdPUb2dOdm/EhapA3m3xBamq+zbeI3e7gVwYoTTT4LquVCNAa4+MnalVnMHyTGR56EJOKdOs2rr8dnMWatQ6P5rt6aZ/Z3sSa5P31qEBx7Q== 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=2id8ByGn4Ivy9z5GM670WdybfgtbuzVd2aEqioHDomU=; b=enDH2QXbcPv11sfQF2dmjm21PgFl9QGlbg9X4mdYXDisnnKYhgZc75mX0RpB4NMDv654JBISJELrzGDHnia8iOJz/i57EwJ0gDnaCzMeQvqrXk+epKsahQna9Gxr2Jg4BL9xBa7JEhPQtkP/mupzSTdveOWUoHyQ8Ak6P8xZgdtqpiN7utNJZucAgsn5YnB2bcTFRV7oDp8jg+C/DYiPBbgFi0mg2AoTNPhyn0ujBak2ozamSp8WSm1pL3u0J0pWjiRCzaegqYNoVi3ssXYfhSn66Z8yix+hzYw41N4vOPF5ditdwaXByk2agPB/pHAecjLuxRXp6Ml3YmzU9y4CfQ== 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=2id8ByGn4Ivy9z5GM670WdybfgtbuzVd2aEqioHDomU=; b=lDIt23gcOiMbpSF2rmxqNERyr7aN+5YsQxCe7B/fkdtuqs5bL7t+fpDe3TpiyGcJsqlVKUtl7qI7KIfxMSIuZGG7ODLtQLD6Hrc/mzyCsC68cEzUvlHeJpBR8QJGK2c9yAvRBNwuC2jWpnj0zMcNFNi72Mx77K+4wDQ4aGd2pKE= Received: from BYAPR10MB2888.namprd10.prod.outlook.com (2603:10b6:a03:88::32) by DS7PR10MB5390.namprd10.prod.outlook.com (2603:10b6:5:3a1::11) 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 12:43:54 +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 12:43:53 +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 09:38:22 +0200") References: <20230711215716.12980-1-david.faust@oracle.com> Date: Wed, 12 Jul 2023 14:43:47 +0200 Message-ID: <87y1jlz4e4.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: FR2P281CA0166.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:99::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_|DS7PR10MB5390:EE_ X-MS-Office365-Filtering-Correlation-Id: 1b89a10b-a7f2-412e-5c13-08db82d5a614 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: weStO46/Jl87UvV9JQXpo9rJPeFmpnNq+GMgxGxbMfix/PwprIEwbbIwd/FMQUo/nS+jJfTZIV7OiEaP6GsNHs8blT+tPaas62icDho0cUxZ+o51FOl3/oE28iJk53AzU8ZGUiZoheAkbtvuGJxRVvj5K4F/o4vOIq3TtkFL2cUeEUotd4Xf2oZSPcwmgagIKdTi2EXbwbIGj5cupyHnm/u0wAIReeoIsaiKbD7P8BDKhEHIU0eRKqtWbJ2WLbPnuQDLl9KEsKmCrvI+s5RK5LhOMbPw8OlymJ2X1l+XhWQVDN30KcAIQ/xZ4bYm+dwRdTdcjO+pvyhQzGviLEGzYtR+tMvccFGXhg51ZPblJyHe+kpiugiGqBk9ry2k477KzzCKuO+WbOrIJhc2OGNata7BHXBqk2kliQ2lAi0pCQtu7g+rDh16MLWZkDebhWSQ/fUVr9Cvm/7WUpk/q2MK5rgseJ85PqWqJIR/G9LGLLHr8pm4NgET6nUynkquzNa8y8ubaqu3yZW5ICUpyZ7Tmo/qZWYBcRoEyXojVzZ+GxddL0frlttNfF9W1ZX+nWjlj0tFTjbFegm9lDxPWsiJ5Q== 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)(366004)(136003)(39860400002)(346002)(376002)(396003)(451199021)(54906003)(316002)(6666004)(66946007)(6486002)(66476007)(66556008)(186003)(41300700001)(6916009)(478600001)(4326008)(966005)(6512007)(8936002)(8676002)(53546011)(86362001)(6506007)(5660300002)(26005)(83380400001)(2616005)(36756003)(2906002)(38100700002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TWVJeDZKbGFnKy8zWWZibVhEbUpTRHNTaWhPakJUdGw3UE1rV29hSFZ4TS92?= =?utf-8?B?ajEyQzM2MlFiVlBRSkVnL1hVNVgvNkpPRTltTXd1VnVtQ0U3UVRNWWZvTHFS?= =?utf-8?B?MlZMUVlHSk8vck5MSFBPY1c3ektZUzlUMzYyQ0VHTkd0SWhnNHNLYmNNeHhW?= =?utf-8?B?YnEycFR1VTg5WUFaZVd5Q0pPbjROcTNzUVFxNUpIUlpUVkJKQ1FFb0FZd01n?= =?utf-8?B?ZkFZQ0FYWHY3NHNuNWdSWXpKQkdxV3ZHWEI2ZGN0REdQRGJCaHI4bG1pRVFM?= =?utf-8?B?WkFaM3pBK09rWld0QWpXK09TU2RlV2g4ekFTaE44UDhBV29KSnlBb0x5Wnk3?= =?utf-8?B?ajQ4b1lBQUZqaDhFaFVLWlc3T3J5c1d3WEg1NFJZNi9DbjhsMk00eFh5MzVE?= =?utf-8?B?b2JBOW1iaFJBUVliV2ZlcUtJbmpmV3JFRDFBZS91ZnRVUGlCWTd4U0hxYXI3?= =?utf-8?B?UWVxS2p5bGRBWGhWY1JvS3JkTTlBK0hYS1oyd2dzcXg2K2ZIOFdycVg4RmpQ?= =?utf-8?B?K2N0SkpyUS80YUVZb2ZDY0QvVjRSSWlxZWkrMlRIQXVjVWdXbzVFQUpzR0R4?= =?utf-8?B?VUZVem5EQys5TDdTUWEvbkxiUFU4T1gyL0RhMTZ4N0Z4NzVsTXdXT05zVUor?= =?utf-8?B?Ymlob1U5SlJlZnJna09ud0w4UkRNUUl4UWhlWUs1aG90R2ZuS2JhMldQSnQ0?= =?utf-8?B?N3g5aHF1Q2dYQXJBWDVla203enNjMnlRTGN0bHFJSTdCS1l4cGFFSWNnL1dU?= =?utf-8?B?N0pGaWJDVmpURy9DZUlFVWRBMmx4emhtRTB6ZXI1U3FaeS91RGNpR3JEdUtH?= =?utf-8?B?MU5VNHlQQ3pYNm15N2RVR1hNODNOMVh2RG1Bd0xhbTNrQzk0Njh1cElQZm1Q?= =?utf-8?B?WkxMU0hScTAveHkxUWNMU1hvRDh2L3NTWm1jbk1zNWxud2VPT3BOWmN4NXFJ?= =?utf-8?B?NnRoY3Byd0xYNHVUTUNJWHgvZVNNTFlUVzVBeTZyYUJhNlZONEtzQzM1T292?= =?utf-8?B?TEtubnhlQjRDbGd3WTNjQW5vUGtsVkErRktNSU1WYUR6OSt2bExYZkcxSWpu?= =?utf-8?B?QzlkMHJXbEJyMmo0TFZmTmhkNnBNWjJtL2JtbWh2WVhHWll3RnVzMGNNL0Zk?= =?utf-8?B?TVRyeXVkczNKR2FGdm9HV3Y0M0tDVlN5R0pEKzlMbzh4RG9EdHhRUWhWNElp?= =?utf-8?B?aGRva3orRm5naUMwOFlEL3hJd3Bqd1hYUnVPeFMzQ2VlbnNMYmF0UlR5TGpK?= =?utf-8?B?OHdLZ1Q2MUNCYXVFNWsvQ1o1K1NWOXljQVREQlhDTkxraXBqQXVXQTFRS1lF?= =?utf-8?B?V09vRFdtNEt4Z1lNTHVpem94SGJlWjhxaUdTODNwTkxZKytFWitUZlV6NHlh?= =?utf-8?B?MSthWGIra3N3Wnd4Q003ckxJS1NieFlSSE80NnRMWllIQnBvUzBoVk1GVmNF?= =?utf-8?B?UTNqUUt3dVp2Y0htTmxHL2kzbjgrUW1MZGVES0J0YWRrZUEzNWZsdm4wWTF3?= =?utf-8?B?bGhDT1BaMnUrYTgzN1V5dDE5NnRzWFZsN2dYSEordjNOMHJqSWp3b1dOdmNY?= =?utf-8?B?bGZKM2pleTI1bTdabzBzaWVTVkdWWHpvTEZDRzZCelJMb1J6SW1WaW5YbGph?= =?utf-8?B?UkNxaGwwWXV4b2NjdExQblFSVUQyNlJnV3hOeDBUdnlEaEJRQ3NxcHRTdnhB?= =?utf-8?B?QjZvZThoUE9IZTlsRjZVbC9rd3BsYWIxZUdOc3doU3Nnd20zbFJrRk80aEYv?= =?utf-8?B?V3lvQk9SRnFTdkRkMkpmTnZZd1I0dTBRSGZ1V2JrRWJOdmt1ckVRcTArT1Ur?= =?utf-8?B?S3lGM3NUY1BxUVhjRnkvMElMbkU1QkhhNFlPK3d0WFhDQlV6eVg4VjMzZjln?= =?utf-8?B?REFRWlFBeGthSmU4VzA0cTMwTFo5YWFjbTRLNWNpMmxWT2oyZ2l1KzdYMGcx?= =?utf-8?B?OFUyS0FYbVBGTUV0em9mUzVKeFhJZVloYjh4RjZ3ZTlXbVpSNUcwKzF6aVJL?= =?utf-8?B?aG92RFltOTFDcVZOcFEyRW54SDBaRk9PdkM5b0J6S2ZKdFA2S3dBQ1RLbnNs?= =?utf-8?B?OWVKR29NTkFZeTRBVXlCOWZBWHZuNFRaeUdJSXE5WkFRZ0VROG9vaHd4VXFm?= =?utf-8?B?N0Vubnk1NkhUVlRQUnZOU2VrK3dLMVVCVE03OFl5U3U5NEpNOXloelcvRGk2?= =?utf-8?B?Q0E9PQ==?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 8ytGPJfztcbzQxQR2KthlxW/+n/LMgaiuSpAv7MTva6BbYTUqSDz+rucTc/zssTJWZkwjMrA/PbuqoKdMuYJEaTKrXZVo/BpH1x/7esojWxVLgGmBhGyoMieuboSAT6hD8NxlvI5e4QR+xnN8VLdDJHC+FMMF6m3Zp3gpLQaGaQZVor/p7WtQaIF3bO/7X1sjOj+8S+nBy+CjF7t9AOf81gybYFF3U4s6OIOpJeVubyAHK+yV9LraWbiuaUJh2nPezjnAnJ7FYqgQ7u8GNkxtmwa+ZkOuQiKPryFYQEJleh6jeCXA03bV7cYjUp8MgBWhNp4tcVQ4rWR5EDPv+m1uq3/OSXqBuiGf2NH5ZDjKuXLsFL7XB2wpAYVsJgw1/dZyyXPYh9I4j8ro0D+7O21FMCet3cxCbCm3c+JQcgW5ZeDB1+Kps68860PnTgjyimszWBgxeeJ3LJ+Udny5+dahoxStVCbqm0cu7rlgPdcAME9AE3uNnhOtmRDh7i/vVCzMdbgJGuJeBryRON+ATw+awD9iIY886DydzsF0+jy9C8k2x/iVl2v2ps1S4+ErdONErgU/UCrqlBril8L+UiJY1YMTUim0ohOIikPmeblPihbNKcrPYECEJhZSh387Mg1XqcY0gHAjiDVTsgECjuN7cHBOtQIXK059DmMItp47vshNRzNg5/lqCijwtieFH885Un4lRcGeKwZ/jicLicklHEbaCm/NDlIm7qUv/84dNWXfXVXT3bOOIKqHryfl1qbCgEXmGGwhK0iahcxaVhOFule+EGp+h7OZUFxv8ug0exBhowCg3kZXeoXL4//M36r X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1b89a10b-a7f2-412e-5c13-08db82d5a614 X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB2888.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jul 2023 12:43:53.1851 (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: tPmT9HIEzehb2ioJx4BHm/mj2I1brKk7wtJLzPjIG4dzyOl0ux0FjD6mfa00HKBfrCPId+PvO3mQkbwffm4dm2F+8+lSFw5yEX4YG8HLnyw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR10MB5390 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 bulkscore=0 mlxlogscore=999 adultscore=0 mlxscore=0 suspectscore=0 malwarescore=0 phishscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2307120114 X-Proofpoint-GUID: -hsb8KMfNymqLZLmiVw3gVTK6dmk_5eb X-Proofpoint-ORIG-GUID: -hsb8KMfNymqLZLmiVw3gVTK6dmk_5eb 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: [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 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 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> 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 BT= F). >> >> >> 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 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 ("devi= cemem"))); >> >> 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 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 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. > 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 records = refer >> to the annotated object by BTF type ID, as well as a component index whi= ch is >> used for btf_decl_tags placed on struct/union members or function argume= nts. >> >> For example, the BTF for the above declaration is: >> >> [1] INT 'int' size=3D4 bits_offset=3D0 nr_bits=3D32 encoding=3DSIGNED >> [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 >>