From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by sourceware.org (Postfix) with ESMTPS id AC0823853809 for ; Wed, 11 May 2022 18:44:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AC0823853809 Received: from pps.filterd (m0246630.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 24BH3oLH010445; Wed, 11 May 2022 18:44:36 GMT Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.appoci.oracle.com [130.35.100.223]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3fwf6caf3g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 11 May 2022 18:44:35 +0000 Received: from pps.filterd (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.16.1.2/8.16.1.2) with SMTP id 24BIPgFp010513; Wed, 11 May 2022 18:44:35 GMT Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2169.outbound.protection.outlook.com [104.47.58.169]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com with ESMTP id 3fwf7axngd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 11 May 2022 18:44:34 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WVbIBfLLj4weTJXuCEJ2xou1k7i+Onk3JYAxc2ziuONksB67eLdvmgu30T3LOr7ZSg2D8XQI2y4i849DkTBuJICtQvZSn6Kon5pVraZtYcaVLFkOIZ3qmIWacxFOFfW/HvFrnRw4Js7COp0VJth/zT051kDOuSvBhKcCH11GzMf63av9UrODXoO0/b3fDfJ7qu3a7re9zjYgy/c5HpT16SY4U6K7OsowuwGdPPbqh10S9jYBsznwdfv7QCuNBKA5kjJWZgIZeVjOeqYpis3SxAPIR0f9tUajxTXAsxfEQmYptj4EoFXcOV9Hv075xLYixaXM+Ygc7IhP7mkiIXJGCA== 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=+PXAl68wZD7K0nBumpV4MwrTPopvNdRiLvFnSrzhxzY=; b=SeVQ4uxX5mhZ8Ls1r5m6It/esP/BMcgxWlLU2tTxj1fiOULScaFDw5xhsuTv+c2NN4BA5wudDzak3twlzVwnzuufhHAS4qLoF2vs45sjdw5BRIBN7qLDUCO5nhI+6tGdajXDUCpWlmGhXsSjZqKOmiRzpdlV450fhpkokCZXibSFb33KvYsGAjR1/q7TL4ag8TZtV53CbXVBz0cklfgc/q9XavCnIeVBmsI4DyakGKvklU0WELudzOYMLdrLWG+edIbDBQZAJgh4klTg3tscFklPtY+GE8BgQ5HtdIMtogV0GkOSsYNLHbOB1V1yitpytm1Mb7cXQNytapCpeJnG2Q== 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 MN2PR10MB3213.namprd10.prod.outlook.com (2603:10b6:208:131::33) by SJ0PR10MB4478.namprd10.prod.outlook.com (2603:10b6:a03:2d4::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5227.21; Wed, 11 May 2022 18:44:33 +0000 Received: from MN2PR10MB3213.namprd10.prod.outlook.com ([fe80::483:8783:8421:5be5]) by MN2PR10MB3213.namprd10.prod.outlook.com ([fe80::483:8783:8421:5be5%7]) with mapi id 15.20.5227.023; Wed, 11 May 2022 18:44:33 +0000 Message-ID: Date: Wed, 11 May 2022 11:44:30 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [ping2][PATCH 0/8][RFC] Support BTF decl_tag and type_tag annotations Content-Language: en-US To: Yonghong Song Cc: gcc-patches@gcc.gnu.org, Joseph Myers References: <20220401194216.16469-1-david.faust@oracle.com> <7419ae42-55c8-87d6-2a19-74cebff51fb4@oracle.com> <7125844e-f538-faca-1cdf-5322492c00d9@fb.com> <54eb0e21-cbca-dbf5-88f1-d8febd091be8@fb.com> From: David Faust In-Reply-To: <54eb0e21-cbca-dbf5-88f1-d8febd091be8@fb.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: BYAPR08CA0032.namprd08.prod.outlook.com (2603:10b6:a03:100::45) To MN2PR10MB3213.namprd10.prod.outlook.com (2603:10b6:208:131::33) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b00f7dfd-00cd-4772-1aa0-08da337e4a46 X-MS-TrafficTypeDiagnostic: SJ0PR10MB4478: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: OepfJOus/VuL0rLX3ZPJOVfq0dRRUrnapKXxQ6Cmu4HkC2dEq1sSDolo/2cU6LtECDzgDGbdB0IxETY1Xi+6zb1sLnPQNJ0L3OM9ATeSC5W324oxRU0WvSdIj7Km2ayetLWkOY/O2zdzies5swt90Qjw5U6GQ01bbhYRrWnaH/Vix9QHV2lmDg/5cvHiMVCwdM/1yMvroxacklPXclQy6Mulzx524So24j9QPF0ROOg2IpmMpBAOuBWHyxYyKj4HN1g67+OkrMJHcP2DBdH3tMZ66gifK4tTWy0uml3s63JwzDnoYjpDCes4an+FtbaDWZVHWGRVbAeonV+PbShhocYuaAIdXlWbYbT+ua6Ue5V/Zywkwn4pt5itFNdMmR1eW2Og6AVI7UjjKekGn0EJTGjHxrAEGlHv4KAfWCESVnp2JTDz+YHq1l5M6JmY42Kwnav1LL0+4fo3UmIgdlWtVTL6QCUf8phbXdoSFm1W1ha6W5eB7R0xFAsqQ49S1fBhE+WEY2Hj6btkYLUTHEvfoGIcRDkI2TQuECEIGdgTccwdcAfm+QBt3wNhUU/8mTgIQXM0YmP7ULErZH3hcnJ/GR2Yo0SAjr8sDeED1/KImAUEgB6S7+elpSq/nPbYGxs4qm//N9gSDYRi4kEfpRnxFkK0fFPvnhWRTf1x+u3v4ojK5ixjVQefalS1pKXQCW4MehsiFdkPNj8zQX4oLeLHKvKoL5HuKatdIBKSeQNzdTl9Rbu6LCl4pLkAIDFO7H8k5cMaiuJIoviEGeGxkzqKQR0fi33ZisjcEA5SAAT2a8dhBHT62vbkBbkLbCIuhYnV 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:(13230001)(366004)(66946007)(186003)(36756003)(83380400001)(44832011)(66556008)(66476007)(31686004)(8936002)(5660300002)(6512007)(2616005)(8676002)(4326008)(53546011)(86362001)(38100700002)(508600001)(6506007)(31696002)(6916009)(966005)(6486002)(2906002)(316002)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MEF3Z0tTTzZLVVJLMmtWd0NtbjlnUmFvREN0cTY1bFlWNldRSHhpM2JIWVJI?= =?utf-8?B?YVgyMGxCekQ2KzZhaHErTUZ2Zk9xMmpNYzRLMVRFajdNblFkYUg0Vi9sOGFJ?= =?utf-8?B?cEU5NHNVN2tndEc0Q0tXSGlyZHJmbldSWW5NamFpQXVkSUFYSmpQclArRkpN?= =?utf-8?B?cGtFMXNvUTQ2NmY1bWxZOUlRZHl6TkNQRUttVVBTZ0VmODNFdytHR2lGQlh3?= =?utf-8?B?di9LOGoveXBjV2hzbTl1a0hqeHFBL2p6cjc1RzE0KzVWQks1eWVsS2Z4eE9x?= =?utf-8?B?VGY3QUFuL1VWU0N0ZWlaUXUzMzdrTURFNWk4OCtPL202dXpERUl3RWF3ZlAw?= =?utf-8?B?YzluZkxjbkcwVS9uNVdPbkgzY2hpYmR2UHMrc2dBSXl0U3ppQXM2QzIwY3VL?= =?utf-8?B?YXBOOEd1bjFzTS9xeEN1V1RRZFJyTEdjdmFoT0tQc1EyMGNwckRtSCtZUkpP?= =?utf-8?B?NWtMTk4zY3F5RUN3TWh2dk5GYnlUWTVlcjdqWVZNcTBxTUl1TThtRDlZS0FN?= =?utf-8?B?QXlqMDFjeEY0d0xUZlFONG1wMkZOTm1lTTJ6SHNiTXA3QUpZdTVVYVp0N0sz?= =?utf-8?B?VkQrZ1FhT2pTWkw1RUtLckVsTjdrMExKNllnOVVlb3ZBSnBHMFQ2TnQyTXZs?= =?utf-8?B?Ry9aYlF3Ny9rTEtiNHRVdThmL0syU3JEaU01SnlXV1hwMTJxUm11V0t6RFE1?= =?utf-8?B?TUVUVlNNZWllWXl2VmZGWHJMMGRNQzhvVDNFQVJ2a0VmM2ZJS2pZc1E0djkw?= =?utf-8?B?U2pGL3l3WlFCZGJCTkg0b0VMWE5hdThOcVc3ZzN2aW5Yd1o4QzdheW5WSkxv?= =?utf-8?B?ZnRxMlVaYTFNSElqOHVUcVkreE1mb0psaXZrOFhjaHRFK2NHR0FaZGIrNjgv?= =?utf-8?B?ODBEc3ZWbXB6ckdEdXpKTjZhVng5a3VYQmVGcEN2MVYrMkVCYUJ6em5HT3Z5?= =?utf-8?B?TUJUMzU1VW4xSzRKMkZpL29GamlwanYyZWIyT04wVnhXeXFnR2lGNEJIeFEy?= =?utf-8?B?S1JodjVHU292eHBUaUNET0t5dndaWnVIZTBKUXUzVzN0eGNYeVdsTDNGRVZI?= =?utf-8?B?OUJBR0ZVNk1vZytiVHNwVytwZlVYY3RQMmhnME1tWmtaRDYrcDIxNmlnajZk?= =?utf-8?B?T3FTTEd2a3R4c0J6b0pTL3hid1Uwd0RlZmgwaW5rUGZOczNZeHVtM3Z1alZv?= =?utf-8?B?R1IxdFdCN2MvRjdaTkVjY0wyR0R2Qld1WjFhZlRtK01UaTlQN0R1YkdUUmQ4?= =?utf-8?B?c01qaUJZNFQ4NTR2emlZNUcwZk9SL0dzL1ZpTTRhOXF0dmMxbnpjcDJNbWxW?= =?utf-8?B?Nmg2czFYWkZmcktFNDNDVXBTZjlXa2I2cG16UGl0bkI5S0xRWnpLUkpRNG9H?= =?utf-8?B?TzNsZEcyM2x2YmtJYktOUmJRdnZnZ2gybmlZNENGcnRDRWN6bWc2RW92Z2R4?= =?utf-8?B?WEVkNFlnMm1DajBwQVVlb21PVmJNbHNqc09SS1lkYzBrbjhCUmpMZFV2TzZN?= =?utf-8?B?bGFlWW1ZR0RkWGFabzNoL3c1a3BJdDBIZXNlZTd0QjBSRy9mWVNsS2ZySytQ?= =?utf-8?B?K3RPQURDRXJ1a1QvOVZwUjJLeS9zdndvM0M2Nk1NaXAvVFhxY1hOTGtEQnVK?= =?utf-8?B?YWdYdXFoZ043bDQvY2VGRUpPWkdUaGI1QzBkbkVnOTUxS3lQc3hlM3MwdUIz?= =?utf-8?B?ZXRJSHYzY1VzWkNxWUZlM00xOFhEZUd0TUxxSDNEYlF0Q3ZJYSsyNmVwRUkr?= =?utf-8?B?dnp0eWsraEFXbDNHR2E4QVppbUZQOU9mQmRLdmgrUWNtY2xnZlVLWXl6K1pC?= =?utf-8?B?OU9tdWdwQ0NldHF1NXpMQkxtNGkveUwwSnNiWmltVHNrTkM0N25KRkVYRDEz?= =?utf-8?B?SURpcExlRjNYN2Z4dkd3Z0lNVzJZaS9TVjdEZEdLS3R6azkvVCszSm82ZHRQ?= =?utf-8?B?ckhTMHhyYWdEbDNTOWMyd29Id01SUjZPNkZkWjZuM0dPWEVWeW5GdUxoRy9m?= =?utf-8?B?NDM1OVJ4a1ZwVkNncmZaTGxLcmkyaEc1YUZmTVBBTHJXT1RYQU5seUNYR3dn?= =?utf-8?B?WmhlUk02RXQrWHZYTmU2TGI5dkhQK2lhanhOb0JrOVl5MW5ldEVpaE1Eay9Y?= =?utf-8?B?UHBlQVVKUzhoSU1RNlhJNFlNRU9FQ2ZVZW9McExhYmZaUkNUMTRFa0hvUy81?= =?utf-8?B?NHpVSVRvSi9KZGFSa2grZUYraUFidGdmQ1pkc3ErUDI0V3BYY1VDN1JKVkF1?= =?utf-8?B?Sk5oQXQwNHphTG0yUWhzL2xLWDlzb2VNRFZBOC8yK25TRFBQVUFBaE13Z1BI?= =?utf-8?B?RXl1ZU80Nlk0L1VseWZ6Rzdhc1JjU0FoRHNBZzJYbXVxRVVoWkdTWGdEckpO?= =?utf-8?Q?jwIEttwcUNH36HJQvIFZFQAYDmC9R1DIAo3aK?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: b00f7dfd-00cd-4772-1aa0-08da337e4a46 X-MS-Exchange-CrossTenant-AuthSource: MN2PR10MB3213.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2022 18:44:33.2288 (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: y1EPFmqpcIFd6sYH83MAZGtJhEIUrJBGnr4EwX674a/13TnBINPOpXZv79H97mjpA2nZlMNS/J90MNhzxGwgCg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR10MB4478 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486, 18.0.858 definitions=2022-05-11_07:2022-05-11, 2022-05-11 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxlogscore=999 spamscore=0 bulkscore=0 adultscore=0 suspectscore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205110081 X-Proofpoint-ORIG-GUID: 01MCKObcRCLHMSSlYMgpiQW0ng9COfN7 X-Proofpoint-GUID: 01MCKObcRCLHMSSlYMgpiQW0ng9COfN7 X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Wed, 11 May 2022 18:44:42 -0000 On 5/10/22 22:05, Yonghong Song wrote: > > > On 5/10/22 8:43 PM, Yonghong Song wrote: >> >> >> On 5/6/22 2:18 PM, David Faust wrote: >>> >>> >>> On 5/5/22 16:00, Yonghong Song wrote: >>>> >>>> >>>> On 5/4/22 10:03 AM, David Faust wrote: >>>>> >>>>> >>>>> On 5/3/22 15:32, Joseph Myers wrote: >>>>>> On Mon, 2 May 2022, David Faust via Gcc-patches wrote: >>>>>> >>>>>>> Consider the following example: >>>>>>> >>>>>>>      #define __typetag1 __attribute__((btf_type_tag("tag1"))) >>>>>>>      #define __typetag2 __attribute__((btf_type_tag("tag2"))) >>>>>>>      #define __typetag3 __attribute__((btf_type_tag("tag3"))) >>>>>>> >>>>>>>      int __typetag1 * __typetag2 __typetag3 * g; >>>>>>> >>>>>>> The expected behavior is that 'g' is "a pointer with tags 'tag2' and >>>>>>> 'tag3', >>>>>>> to a pointer with tag 'tag1' to an int". i.e.: >>>>>> >>>>>> That's not a correct expectation for either GNU __attribute__ or >>>>>> C2x [[]] >>>>>> attribute syntax.  In either syntax, __typetag2 __typetag3 should >>>>>> apply to >>>>>> the type to which g points, not to g or its type, just as if you had a >>>>>> type qualifier there.  You'd need to put the attributes (or qualifier) >>>>>> after the *, not before, to make them apply to the pointer type.  See >>>>>> "Attribute Syntax" in the GCC manual for how the syntax is defined for >>>>>> GNU >>>>>> attributes and deduce in turn, for each subsequence of the tokens >>>>>> matching >>>>>> the syntax for some kind of declarator, what the type for "T D1" >>>>>> would be >>>>>> as defined there and in the C standard, as deduced from the type for >>>>>> "T D" >>>>>> for a sub-declarator D. >>>>>>   >> But GCC's attribute parsing produces a variable 'g' which is "a >>>>> pointer with >>>>>>> tag 'tag1' to a pointer with tags 'tag2' and 'tag3' to an int", i.e. >>>>>> >>>>>> In GNU syntax, __typetag1 applies to the declaration, whereas in C2x >>>>>> syntax it applies to int.  Again, if you wanted it to apply to the >>>>>> pointer >>>>>> type it would need to go after the * not before. >>>>>> >>>>>> If you are concerned with the fine details of what construct an >>>>>> attribute >>>>>> appertains to, I recommend using C2x syntax not GNU syntax. >>>>>> >>>>> >>>>> Joseph, thank you! This is very helpful. My understanding of the syntax >>>>> was not correct. >>>>> >>>>> (Actually, I made a bad mistake in paraphrasing this example from the >>>>> discussion of it in the series cover letter. But, the reason why it is >>>>> incorrect is the same.) >>>>> >>>>> >>>>> Yonghong, is the specific ordering an expectation in BPF programs or >>>>> other users of the tags? >>>> >>>> This is probably a language writing issue. We are saying tags only >>>> apply to pointer. We probably should say it only apply to pointee. >>>> >>>> $ cat t.c >>>> int const *ptr; >>>> >>>> the llvm ir debuginfo: >>>> >>>> !5 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !6, size: 64) >>>> !6 = !DIDerivedType(tag: DW_TAG_const_type, baseType: !7) >>>> !7 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed) >>>> >>>> We could replace 'const' with a tag like below: >>>> >>>> int __attribute__((btf_type_tag("tag"))) *ptr; >>>> >>>> !5 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !6, size: 64, >>>> annotations: !7) >>>> !6 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed) >>>> !7 = !{!8} >>>> !8 = !{!"btf_type_tag", !"tag"} >>>> >>>> In the above IR, we generate annotations to pointer_type because >>>> we didn't invent a new DI type for encode btf_type_tag. But it is >>>> totally okay to have IR looks like >>>> >>>> !5 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !11, size: 64) >>>> !11 = !DIBtfTypeTagType(..., baseType: !6, name: !"Tag") >>>> !6 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed) >>>> >>> OK, thanks. >>> >>> There is still the question of why the DWARF generated for this case >>> that I have been concerned about: >>> >>>    int __typetag1 * __typetag2 __typetag3 * g; >>> >>> differs between GCC (with this series) and clang. After studying it, >>> GCC is doing with the attributes exactly as is described in the >>> Attribute Syntax portion of the GCC manual where the GNU syntax is >>> described. I do not think there is any problem here. >>> >>> So the difference in DWARF suggests to me that clang is not handling >>> the GNU attribute syntax in this particular case correctly, since it >>> seems to be associating __typetag2 and __typetag3 to g's type rather >>> than the type to which it points. >>> >>> I am not sure whether for the use purposes of the tags this difference >>> is very important, but it is worth noting. >>> >>> >>> As Joseph suggested, it may be better to encourage users of these tags >>> to use the C2x attribute syntax if they are concerned with precisely >>> which construct the tag applies. >>> >>> This would also be a way around any issues in handling the attributes >>> due to the GNU syntax. >>> >>> I tried a few test cases using C2x syntax BTF type tags with a >>> clang-15 build, but ran into some issues (in particular, some of the >>> tag attributes being ignored altogether). I couldn't find confirmation >>> whether C2x attribute syntax is fully supported in clang yet, so maybe >>> this isn't expected to work. Do you know whether the C2x syntax is >>> fully supported in clang yet? >> >> Actually, I don't know either. But since the btf decl_tag and type_tag >> are also used to compile linux kernel and the minimum compiler version >> to compile kernel is gcc5.1 and clang11. I am not sure whether gcc5.1 >> supports c2x or not, I guess probably not. So I think we most likely >> cannot use c2x syntax. > > Okay, I think we can guard btf_tag's with newer compiler versions. > What kind of c2x syntax you intend to use? I can help compile kernel > with that syntax and llvm15 to see what is the issue and may help > fix it in clang if possible. I am thinking to use the [[]] C2x standard attribute syntax. The syntax makes it quite clear to which entity each attribute applies, and in my opinion is a little more intuitive/less surprising too. It's documented here (PDF): https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2731.pdf See sections 6.7.11 for the syntax and 6.7.6 for declarations. Section 6.7.6.1 specifically describes using the attribute syntax with pointer declarators. The attribute syntax itself for BTF tags is: [[clang::btf_type_tag("tag1")]] or [[gnu::btf_type_tag("tag1")]] I am also looking into whether, with the C2x syntax, we really need two separate attributes (type_tag and decl_tag) at the language level. It might be possible with C2x syntax to use just one language attribute (e.g. just btf_tag). A simple declaration for a tagged pointer to an int: int * [[gnu::btf_type_tag("tag1")]] x; And for the example from this thread: #define __typetag1 [[gnu::btf_type_tag("type-tag-1")]] #define __typetag2 [[gnu::btf_type_tag("type-tag-2")]] #define __typetag3 [[gnu::btf_type_tag("type-tag-3")]] int * __typetag1 * __typetag2 __typetag3 g; Here each tag applies to the preceding pointer, so the result is unsurprising. Actually, this is where I found something that looks like an issue with the C2x attribute syntax in clang. The tags 2 and 3 go missing, but with no warning nor other indication. Compiling this example with gcc: $ ~/toolchains/bpf/bin/bpf-unknown-none-gcc -c -gbtf -gdwarf c2x.c -o c2x.o --std=c2x $ ~/toolchains/llvm/bin/llvm-dwarfdump c2x.o 0x0000000c: DW_TAG_compile_unit DW_AT_producer ("GNU C2X 12.0.1 20220401 (experimental) -gbtf -gdwarf -std=c2x") DW_AT_language (DW_LANG_C11) DW_AT_name ("c2x.c") DW_AT_comp_dir ("/home/dfaust/playpen/btf/tags") DW_AT_stmt_list (0x00000000) 0x0000001e: DW_TAG_variable DW_AT_name ("g") DW_AT_decl_file ("/home/dfaust/playpen/btf/tags/c2x.c") DW_AT_decl_line (16) DW_AT_decl_column (0x2a) DW_AT_type (0x00000032 "int **") DW_AT_external (true) DW_AT_location (DW_OP_addr 0x0) 0x00000032: DW_TAG_pointer_type DW_AT_byte_size (8) DW_AT_type (0x0000004e "int *") DW_AT_sibling (0x0000004e) 0x0000003b: DW_TAG_LLVM_annotation DW_AT_name ("btf_type_tag") DW_AT_const_value ("type-tag-3") 0x00000044: DW_TAG_LLVM_annotation DW_AT_name ("btf_type_tag") DW_AT_const_value ("type-tag-2") 0x0000004d: NULL 0x0000004e: DW_TAG_pointer_type DW_AT_byte_size (8) DW_AT_type (0x00000061 "int") DW_AT_sibling (0x00000061) 0x00000057: DW_TAG_LLVM_annotation DW_AT_name ("btf_type_tag") DW_AT_const_value ("type-tag-1") 0x00000060: NULL 0x00000061: DW_TAG_base_type DW_AT_byte_size (0x04) DW_AT_encoding (DW_ATE_signed) DW_AT_name ("int") 0x00000068: NULL and with clang (changing the attribute prefix to clang:: appropriately): $ ~/toolchains/llvm/bin/clang -target bpf -g -c c2x.c -o c2x.o.ll --std=c2x $ ~/toolchains/llvm/bin/llvm-dwarfdump c2x.o.ll 0x0000000c: DW_TAG_compile_unit DW_AT_producer ("clang version 15.0.0 (https://github.com/llvm/llvm-project.git f80e369f61ebd33dd9377bb42fcab64d17072b18)") DW_AT_language (DW_LANG_C99) DW_AT_name ("c2x.c") DW_AT_str_offsets_base (0x00000008) DW_AT_stmt_list (0x00000000) DW_AT_comp_dir ("/home/dfaust/playpen/btf/tags") DW_AT_addr_base (0x00000008) 0x0000001e: DW_TAG_variable DW_AT_name ("g") DW_AT_type (0x00000029 "int **") DW_AT_external (true) DW_AT_decl_file ("/home/dfaust/playpen/btf/tags/c2x.c") DW_AT_decl_line (12) DW_AT_location (DW_OP_addrx 0x0) 0x00000029: DW_TAG_pointer_type DW_AT_type (0x00000032 "int *") 0x0000002e: DW_TAG_LLVM_annotation DW_AT_name ("btf_type_tag") DW_AT_const_value ("type-tag-1") 0x00000031: NULL 0x00000032: DW_TAG_pointer_type DW_AT_type (0x00000037 "int") 0x00000037: DW_TAG_base_type DW_AT_name ("int") DW_AT_encoding (DW_ATE_signed) DW_AT_byte_size (0x04) 0x0000003b: NULL > >> >>> >>>> >>>>> >>>>> This example comes from my testing against clang to check that the BTF >>>>> generated by both toolchains is compatible. In this case we get >>>>> different results when using the GNU attribute syntax. >>>>> > [...]