From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) by sourceware.org (Postfix) with ESMTPS id EF94C3856DF3 for ; Tue, 24 May 2022 06:33:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EF94C3856DF3 Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 24NKGctp025865; Mon, 23 May 2022 23:33:15 -0700 Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2102.outbound.protection.outlook.com [104.47.58.102]) by mx0a-00082601.pphosted.com (PPS) with ESMTPS id 3g6yd3dxrm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 May 2022 23:33:15 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aQGcTTxwvyaPw8afN0tzNhV0f5/xrW8F7nivQncnn1j3pWWc3cMc/R3CdVcRxB7aUKad8F6+pWPNKVCGagg7lWTl3R5hJH0jPgirjCNRAp0vg6OxWnHdFvMf3bA7KICkUZOQP4gBhvWeLCA2ftclAWe81q6nDnlk5ZiCobGPL+M0B3WeUMgyTWqgChjIe2t+vVVWgqeurTeIzf+fdr6pk4dfrWp7x/Zx+L28b6/cIwy7YZKZ+h3z0JQp0hwYAUCmwXRw3mCNHfTBByL1EAI30L0qD4ShAAe/zTqNfZ/fdEfl/pIX17WXoHpsbIJsdyUg9onz3oMGNd2eMJyy388FIA== 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=4+87DKmT2Qv3li8RX0tYGBkDi4s5uTpJc7gToSGl9CA=; b=Az88s7RPVLdKTCYfvB4QkLN2BNUUgNV9D3L2499QRIKIEGQm9g9Qo3kYK/oGUd7mY5vAxPW//BZhxQxEeD5bGKg6Liqv4UEQsgQ06/tO9ncRJ4Kb/F1TXCzU3Vlb3dRv6hqE8+9UD68VakKhqfIEYpRjeMEvOPLh0CDsLZ0Ox3oIiS7QoRoc8bjDV2l0GKQSkzmaRAQ+ip0LAFFUfQuNawO9Z+M5Q4dU4gJybaSLQ9HEjZofeUHmV+AzQFatuoqHhA1kQHaY3gK2ny0dul+VHv1zBsMYaYwGUZC7x9DXxN3V4dcY1Vgp1JLvzW0FX4Fw8Yf+syDS/LKySFJ3MK44cQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=fb.com; dmarc=pass action=none header.from=fb.com; dkim=pass header.d=fb.com; arc=none Received: from SN6PR1501MB2064.namprd15.prod.outlook.com (2603:10b6:805:d::27) by MW4PR15MB4732.namprd15.prod.outlook.com (2603:10b6:303:10d::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5273.23; Tue, 24 May 2022 06:33:13 +0000 Received: from SN6PR1501MB2064.namprd15.prod.outlook.com ([fe80::5811:4996:bbfd:3c53]) by SN6PR1501MB2064.namprd15.prod.outlook.com ([fe80::5811:4996:bbfd:3c53%7]) with mapi id 15.20.5273.023; Tue, 24 May 2022 06:33:12 +0000 Message-ID: <9ec418b0-b002-085f-fc89-5a05fc3cd3c4@fb.com> Date: Mon, 23 May 2022 23:33:09 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [ping2][PATCH 0/8][RFC] Support BTF decl_tag and type_tag annotations Content-Language: en-US To: David Faust 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: Yonghong Song In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed X-ClientProxiedBy: SJ0PR03CA0341.namprd03.prod.outlook.com (2603:10b6:a03:39c::16) To SN6PR1501MB2064.namprd15.prod.outlook.com (2603:10b6:805:d::27) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 89f93f9b-1ba2-41d7-98d7-08da3d4f468f X-MS-TrafficTypeDiagnostic: MW4PR15MB4732:EE_ X-Microsoft-Antispam-PRVS: X-FB-Source: Internal X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Lv5Dwxcg/SfsJjUSGg4JGkWk78ODj5mvLTb0cz/rlog6L3zBYBIcb2vwVCt4Ij7SzD6ZS3F/uB0NySpZNBQ1jZtQf2uQ9rI8dUoTnBSwaFCwBNXjVC7RQF94n4X8Qzo/LFUY+v/tw9cKS0Myv5tXURexb//sWetlgchUzElwiWcMTzhix9XVGcdDDijXL7P7+N9pnsMiaa5zcO5Tc8pq/PYys508gnB3cwLTgnvGOZWYzp9fOupmMx3LPBvZHY5bnGHzadoDLhrRGRtJpAbNCCsOosJdIwym+gwWMX3PQLUVyPAcFALRLjytad3QIIvD2QDfIl5etoeJy81ZI2S7fmSGsyeZyFlJ/mD7p+jfes6q6bNq5ibEdGJef9zn9YJksedcjdOBmQb456slIG9a0D+5AxKA9OADUl1Ilx4f2ZyeXfiRdpZd/MsNu+PJ6qdNLRpUbGkppJWl8fCBnHlED1NoZbFE6DFlHuGC8UF7GwpV3yAm4IVisXNegEUhPqyXJYGutKu+iF9aDl4kqOHtKt5nAUhOuhLCBTv+1wT3RGuPKJ4aAyRaBReGpo4zTre69yBKjc0ZrPj8zvz5mjZfzdQ/trycir5VdLdS97Pgj3hJ816tN+INSQR6Msq0dkJlMB2RXoQS3TBzRo+CXxWQQ+kI7cyL/OQ+CrLbO9lrRAme86aVdvy5nNsOC9mwRJEf+NNR9wFSluSBQ9oRLKD9j2nKdVMkMdh6u7lU/xTV/X+5DAhiQA/6jqqnNUDDekVid3fNsWyhYw8zIKzgCHzMmJaawOhgHt4ZNF9hXEcE3zR2+7v8Hi1Vix7Y4bsKn8id X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR1501MB2064.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(6506007)(6666004)(6512007)(86362001)(4326008)(8676002)(66946007)(66556008)(508600001)(31696002)(66476007)(966005)(6486002)(316002)(6916009)(53546011)(2616005)(186003)(5660300002)(38100700002)(2906002)(36756003)(31686004)(8936002)(30864003)(83380400001)(52116002)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?S0tUVUlSTFFKNkQzaDREd2Jna2NGRWQ1OGI2dTdtTGdPcHBGSm1kZ0tQNnEx?= =?utf-8?B?bXZqVVBmLy9tckdkRFhOWkp3OVQ5dDcrWjVqaWV1Z1RjOGFhVjdRS3JITTFv?= =?utf-8?B?bWtyK1BKV1hrelRyYXp4ZU5Ma3V5Y2cyR2Z3cVpESVA5UmRRZ0UyVjZmOUtM?= =?utf-8?B?WHMrb281ZFRCRVpvVC9BUFk3bHNpNDdaVkRGTTBBRzdqcTVoM2hSOEZZV0pP?= =?utf-8?B?VjROb0NlQkFjQ25UeEtQeVJqc2cxbk42bjU5dkYvQTUySlc1MFBkbDVjeTlK?= =?utf-8?B?b0QybU45MnVWcFQ0dElGOHhFaExIKzVVWVlLd1doM1BqN0N0UFJWaFpsWGEw?= =?utf-8?B?RXBhQmZreG9nNDFYQk5uTWdiN2lNeGpuakFCKzd4SGJYdmk3R0p3enU3ZnBh?= =?utf-8?B?K09tbWVVQ09Ib1M5U2kvN1ZKWjNIdzI1U3JpTEFEY2tFNU51cjUyVGFGa2lI?= =?utf-8?B?OHNuYngrUHJsNXlXSHFpci9aenFwcWZLK3JjWngyckcvWUlZaEhIV0lSN0Vi?= =?utf-8?B?Vk41TUJ6QXNzSjUzeXFVWC9EMGxtcTBKK25xeDBHS0N6SzhLLzRMYnI4Ukkr?= =?utf-8?B?UlRDc3R4dExnSTZ2bFpIcHl6TFhFOWw0Ujc0eThnT1ovMThvNXdwaDJ0UHpS?= =?utf-8?B?TTFLQVJ5SFB1Mm9pT05RYUlBQ2kydDcwekR6Zk85UDIzd1U3ODFzMmUwOWNN?= =?utf-8?B?cDJhdEJlYkpDMHgxS0NmYlB5STVBb1hpR3VDbFpMS2gyMklEekJDVUhHK0Ni?= =?utf-8?B?cmsvWk1HS3IzQXNDc29nQzA4ZVNEQjdTWGVDWVZWd2hrK0ZZMFQrMnp3U1VF?= =?utf-8?B?a09VNDdsYUs0dUFQbW43Y3lNSEZqS3lmRDBNazh4MW5Hb2c1TVVmaC9EQXBi?= =?utf-8?B?bE9UL1kxQUtXYUNKbGUxMm1LYjJhVVNleWpRTzBhMjA0QVlRZ2ZnKzN1Z1o5?= =?utf-8?B?dmZrRERCcEtLdEdQVm56UTZPZ0lHQTFpdnFJSmxEdU9mcTlnRlhkNzZXc3Jr?= =?utf-8?B?TEZWcTFrQ1I0T0xXd3FQQ0xsTGd4UGFueGRjU3lTalBWU3BjRnZtUTJ5a1V5?= =?utf-8?B?Z2lRWTduRGZLN01XUW1YKzQ3WlErK0NPYnhKY3BkSmEwRmlDQ3RnWHB2K05Y?= =?utf-8?B?Z1ZWKy9CMUs3SVFZeC8yejBSQnJSKzIvWjQzS2FOWUkxNlJ4L2dBQjhCS0xJ?= =?utf-8?B?RUZJSTd1QVpjejFQSXFzam84YUprVUZXMC9RUEE1bU9yRkVEWnpzNUpJemNT?= =?utf-8?B?MkFwMWRpb1dHWmFLcFFON2pjS0JSTFlwYktyWWpicVNMY3AzbURVQ3pzMzBW?= =?utf-8?B?bFlPcm1VQVFmK1NxYVRvODIzQmNsTHR4SmVKMUgySnZ3amdDM2pmN2orMjB2?= =?utf-8?B?WXZYWmE5ZWJPMmEySnc5V3VydGhzN2MrTFZWZ0tMZzZGMkdwN0N2dmpHdVVq?= =?utf-8?B?Q2U2U2phbnU1TGZiYmlsTUl1RWxBSWFJTVVsMTNWZUJUSDR0OVNYOXExNkxJ?= =?utf-8?B?b2lXaHJUZlFSYW4zQjVYY2dpUURuS2tRaThhQ1IrUnRrNVpwc3FjVU1xdnBK?= =?utf-8?B?Y1o1OTluSDY3bnBwSzVSWFJERXNQTU5pdmRmVTUzOXVOVTBEWnQ3RUZBdDJB?= =?utf-8?B?MndFUTR2MGVIeGcxQk83MUNuR0N2UnA1d2xTaHlCMmwzajMzSDFxdVVnZWpj?= =?utf-8?B?aTNBbnJoZ0RQTEFUdmZnQ2FrK2E3RERhQ25BMzdodTIzc0pwaC9aYVRtTkMv?= =?utf-8?B?c08wOEE5VzZBMkVhLy9qT3Z6RDB0NEJVOUlxMzFmRy9yVE1sZXpMUTBQTGxo?= =?utf-8?B?dzJ3OGlsOGlGS1Vycnd3VHJjSE9UaytNd0c2d2ZyRkVhUThpV0pFUVRNRnhP?= =?utf-8?B?VHRpZVNpbk41MVhhL0VlRG9wZ0h5cEFYeS91a2NlcjhHZDJ4TWJTcTQzeFcz?= =?utf-8?B?MENWbXk2SjlRSllEVENiSG81cCtHbkgvd28waVFuOGlXT0ZUN2ZYemd2S1Y2?= =?utf-8?B?ajJTQ1NwZE9raythelQwaU4wNTRzZE1jdnhMUGtzMVZVQWErazJLaWFXUUha?= =?utf-8?B?M2EzbHIxUXUzY205bllJTkU3VlFNdkh4Wm8ycU9RTm53TWpxZWphQjhvdk96?= =?utf-8?B?QjNpR0tKUkg4RUN6Y004S082TjRKMlphc2EvRnoxL0tLayttaHV2SXJxVEV3?= =?utf-8?B?VTRSTDJhQmRIclVoTTNnbDBqblhOTW9sNkZqbWxrRnJyaTI3SG5pRzdGdTJX?= =?utf-8?B?eS9YU0JWVTZ3T0ZRU1FlN2prUW1JTnprdnYwcFpobk4ySE5jMnZzb2d4N0tQ?= =?utf-8?B?Rlk4bXJqWXZJTUFkMmVBZVlLWTdoaENTS3I4RnAwUTNoT1FSMVVmdDd1dkE3?= =?utf-8?Q?pXxGshRWjphRBpnc=3D?= X-OriginatorOrg: fb.com X-MS-Exchange-CrossTenant-Network-Message-Id: 89f93f9b-1ba2-41d7-98d7-08da3d4f468f X-MS-Exchange-CrossTenant-AuthSource: SN6PR1501MB2064.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 May 2022 06:33:12.3123 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: A+s4DO8oWKLmYLm7zbvESv4DgG+i6wJbGscC+LW0/cqqpYIgGdSFrq1IkSaxdXo0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR15MB4732 X-Proofpoint-GUID: coBsmjtLm3FJlXmmSa5-Q078d_QANbi9 X-Proofpoint-ORIG-GUID: coBsmjtLm3FJlXmmSa5-Q078d_QANbi9 Content-Transfer-Encoding: 8bit X-Proofpoint-UnRewURL: 1 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.874,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-05-24_04,2022-05-23_01,2022-02-23_01 X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, 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 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, 24 May 2022 06:33:20 -0000 On 5/11/22 11:44 AM, David Faust wrote: > > > 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 Thanks. I checked with current clang. The generated code looks like above. Basically, for code like below #define __typetag1 [[clang::btf_type_tag("type-tag-1")]] #define __typetag2 [[clang::btf_type_tag("type-tag-2")]] #define __typetag3 [[clang::btf_type_tag("type-tag-3")]] int * __typetag1 * __typetag2 __typetag3 g; The IR type looks like __typetag3 -> __typetag2 -> * (ptr1) -> __typetag1 -> * (ptr2) -> int The IR is similar to what we did if using __attribute__((btf_type_tag(""))), but their semantic interpretation is quite different. For example, with c2x format, __typetag1 applies to ptr2 with __attribute__ format, it applies pointee of ptr1. But more importantly, c2x format is incompatible with the usage of linux kernel. The following are a bunch of kernel __user usages. Here, __user intends to be replaced with a btf_type_tag. vfio_pci_core.h: ssize_t (*rw)(struct vfio_pci_core_device *vdev, char __user *buf, vfio_pci_core.h: char __user *buf, size_t count, vfio_pci_core.h:extern ssize_t vfio_pci_bar_rw(struct vfio_pci_core_device *vdev, char __user *buf, vfio_pci_core.h:extern ssize_t vfio_pci_vga_rw(struct vfio_pci_core_device *vdev, char __user *buf, vfio_pci_core.h: char __user *buf, size_t count, vfio_pci_core.h: void __user *arg, size_t argsz); vfio_pci_core.h:ssize_t vfio_pci_core_read(struct vfio_device *core_vdev, char __user *buf, vfio_pci_core.h:ssize_t vfio_pci_core_write(struct vfio_device *core_vdev, const char __user *buf, vringh.h: vring_desc_t __user *desc, vringh.h: vring_avail_t __user *avail, vringh.h: vring_used_t __user *used); vt_kern.h:int con_set_cmap(unsigned char __user *cmap); vt_kern.h:int con_get_cmap(unsigned char __user *cmap); vt_kern.h:int con_set_trans_old(unsigned char __user * table); vt_kern.h:int con_get_trans_old(unsigned char __user * table); vt_kern.h:int con_set_trans_new(unsigned short __user * table); vt_kern.h:int con_get_trans_new(unsigned short __user * table); You can see, we will not able to simply replace __user with [[clang::btf_type_tag("user")]] because it won't work according to c2x expectations. > > >> >>> >>>> >>>>> >>>>>> >>>>>> 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. >>>>>> >> [...]