From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) by sourceware.org (Postfix) with ESMTPS id 70B00385625E for ; Tue, 24 May 2022 16:04:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 70B00385625E Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.17.1.5/8.17.1.5) with ESMTP id 24O6fouJ006532; Tue, 24 May 2022 09:03:59 -0700 Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2043.outbound.protection.outlook.com [104.47.66.43]) by m0089730.ppops.net (PPS) with ESMTPS id 3g6uk7smep-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 May 2022 09:03:59 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LNeQwt8IcmDnKwVRmZAH/ERBZ6abVdMLojz0dnFlhb8Kem7iYggNlRVOFwiU21BvITVPv6OjPrrHWiJDovIh+dzMK5aFToDBj8FT6RG+Pnf5rZ1daHVtmGDxwIx7jawGaYQXMpVICKuvULfwFq/Uo9iglKdXYVoa4EvKHcv9q8RTjYfB8J9VBbZ9jfAhO03dYfLprT3xbUEIucbfTUhkGpTmAWVI6VHiUdubqO4NHz4Sg2+a3WLn/P4PWkV3ARLaGpe5/wb2B6UG9zLCJOaGz/vt/Ypjq/bQaBnX4SikV4ZeQLnss4Rowp45REyWy9WpydZhY2yUfCsSJpNA4B5k/w== 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=eV2mdmJpdfJYbZMb3nx7CHRAgOAalZCEdg3njyZBS0k=; b=LH6xyhSH9ZZWxxrLgtC9a1E4gn+jpIWlV29J9gbcao0s01B28U69nArsrFjOXswF6fW/+hJXMNa5yqrUPZc/19C1kDyhKJ/tcXDbeBAHUQ7wahagPQOvq4IRug1mMZE4Ly4hqCe7H5qIf5zzgaFCq2TXHcXhqgGWrAFlLyQJabMGRQKRqPy0YMSJKn025t+tP81a46CyGyjS/wVftWPpB+VWSqRF2nchBJ2NQrcZ+7jQkktumTq81KFHOxy8kWp86qX9BVChUcF+w9xZWpyRIHylP6xUP//60oTbq3kk8xDOTxyzFf28tTOoEP4okFRD1P+LRQramtdYBFXiR1Rlpg== 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 DM5PR1501MB2055.namprd15.prod.outlook.com (2603:10b6:4:a1::13) by MW3PR15MB4026.namprd15.prod.outlook.com (2603:10b6:303:50::16) 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 16:03:56 +0000 Received: from DM5PR1501MB2055.namprd15.prod.outlook.com ([fe80::29c5:e5e5:39e5:7df6]) by DM5PR1501MB2055.namprd15.prod.outlook.com ([fe80::29c5:e5e5:39e5:7df6%6]) with mapi id 15.20.5273.022; Tue, 24 May 2022 16:03:56 +0000 Message-ID: Date: Tue, 24 May 2022 09:03:54 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [ping2][PATCH 0/8][RFC] Support BTF decl_tag and type_tag annotations Content-Language: en-US To: David Faust , "Jose E. Marchesi" Cc: Joseph Myers , Yonghong Song via Gcc-patches 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> <9ec418b0-b002-085f-fc89-5a05fc3cd3c4@fb.com> <87h75fxk80.fsf@oracle.com> <0f4fcf9d-c0ab-6221-063f-67c1e6808fe1@oracle.com> From: Yonghong Song In-Reply-To: <0f4fcf9d-c0ab-6221-063f-67c1e6808fe1@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-ClientProxiedBy: BYAPR01CA0002.prod.exchangelabs.com (2603:10b6:a02:80::15) To DM5PR1501MB2055.namprd15.prod.outlook.com (2603:10b6:4:a1::13) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 86c4b90c-a381-489c-2549-08da3d9f018c X-MS-TrafficTypeDiagnostic: MW3PR15MB4026: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: l/rUDgY7RLTt5JYbApks4tvq7Cjlf6mFQo4mkpeZH7cawpDIRtTVXPRB8oEZVWSSelin5OBeuW9Sp01XOmAg0KXBLmo1MZtiAr+Ye7Ipmqs8IK9DtyIxeFE8JrAG3tDb/ADK7VRFdRNX3wSM9PA8ckO3CSykR2Tw/oWiMtvZmQvVlAP/hzOpaIfuopAA1W7EgSNarZHShwuZfbvkmYD0mTh3GMQZcMyusMoQT44Q08vXfFz5uque5IFACnuMQWwYmtFHDtryWviCU6rht7u9/YRufYEYVLQtmVApz/y1H6GlSGZeBjzz9yFQSjNLLspZq9PcekIqC3zho84E1f/4TcKUvDcTdScSETiX1pmk4Z/PptaUFXIHMtJw+wJBhe7E8w2F7pzpVw6tQmkuEfYaybiF4z+d63lVDPS/wH/4L2Jvej9OlJGI3b/0DanZ+yEZmzCvzjGJhpczkFjVKv+oPdFRIM/xDYEKATs9U4qbEDYH4kFTJgI8LsnQ1/lhrmr8U3eYeo8i6tce8rhC2uXAmGibpR1Ao+t1yshQgUGaNZnahPMX1hbNDmn1QMh1Hf+4lfQ7Rz9p5hzv2neAU2pTHkqcqILIIg+vcIgsCpD7ZjEglM3MYdOJ86F5qjhguSBDMD9CpntM3IEPzcmaXPbVN+J48E3BgNBIItPMvXHC2nNRtoZEuXzCQJOcdTFnGDofL3vWlpSE8WNGh1jlliY5XjPkYY19ZfWRJNKaM3ErghIyIZw3tSwXt52vMOavZpCTG1z1O3jR5tHits2qPpXnYTpoFFtnSsDPqTF/OkZI8CDe9kBNj4ElS5fQdrA8/cJS X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR1501MB2055.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(6512007)(110136005)(2616005)(31686004)(186003)(6506007)(53546011)(6486002)(36756003)(508600001)(966005)(8936002)(2906002)(5660300002)(8676002)(4326008)(66476007)(66556008)(66946007)(83380400001)(30864003)(52116002)(54906003)(316002)(31696002)(86362001)(38100700002)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OFlqaHJsaDVpczQwMHBja3VXU0FHMi9EdEN0RTh1cU5jaTZSSEFPSFo1bHQ2?= =?utf-8?B?bEJPUWxWbURSSGN0bDczR3prL05mSzJJQzY5Z092OWRMOVFFOWc0NGtlZ0Ri?= =?utf-8?B?ckRCVU0xblF0Vno1bDlwdm1qRVpibUNIa3B6NTBsVXFOaFZiQVlyN1hWc0xt?= =?utf-8?B?TlVPdUpMWllGdEVjRFNWVmw1MVpXWm16YjUvalhWRmJxaGd6d3dMMmJORXda?= =?utf-8?B?U2JkZUZEblAyc0hGcERIL3dqS1VWQXIwVG9TNytQaFJyOGhGK0RTNnlwOHZr?= =?utf-8?B?Vk56OCs0NW9RSk9TWUZleUhZZHFaRWQ3MjhhemR0N092MDlzOEFNR3VDREpT?= =?utf-8?B?c1VaY0JpZkR1MFh4VnY0QnhmQk1SbzlMWEU0ck1DZWFnMC9DMi9jR3lKM05k?= =?utf-8?B?T1JCd1BrN0t2bTc1WWNndm5lNVVsY1U2amQwZ2V3L3Y3NmhtVDhOME9YYkpw?= =?utf-8?B?ekNMRVJhUnVqckZGdmJhU2ZBU3A5Y3dCbzNEVFZPanJ4YU5hN0g1S1BCVDdZ?= =?utf-8?B?a2FXcmd6VTM2bUY3dVZGT0w2dUhKYnB1dmRRSytjdWkyeXdHcE9uaDlLMzhP?= =?utf-8?B?bTVMTEdEcTFoY1dqTGoxa0REOHh6K1UyNTBLRTdZVnluV1pJN25IUVNCbC9l?= =?utf-8?B?Sjd5WU93MjUxeG9ESWhtdUpXYzJ4bWJqakZVbVVSMTcyZVkwT09MUmNweXpT?= =?utf-8?B?d0xmN3ZxaDh6WWpteXJZTE9KRmFYTVgyZStCU0FxejlFb2s1ci9qdytwaVlB?= =?utf-8?B?YVM5Ylkzb1FZVlU5RGVZY0IzbGtqaEFXNXgrTWF3a3dJZ2VYRXVMdGwyNjNr?= =?utf-8?B?WVBVTWdXL2lnSjdLVjZUTjdJTnZRNmtxRjBLTzlRbEZYcmtKUFk4MjBQNm8w?= =?utf-8?B?d0xGUGlhSW9EVXhGai9mQmlIMWNRWnZqTWNwb0dJdlMxWElDRTZxWkdmK1A0?= =?utf-8?B?akJCdUhaUkN1eUpNTUlNcXNTQTJzRGFJd2s2d2kxRU1sY1d6OEdxYzE2RmRB?= =?utf-8?B?RS9MbnUrWkdpTTdrSi9kZXJadTRUNnhFYWo2L0wwRDNRZnlLSU5Db2lMSU9n?= =?utf-8?B?T1NMUldHb3BsZlRhdU5ZMWRQdllRUE11RVRDd1FqZGdqcktMMmk1S3hxMUFQ?= =?utf-8?B?TEZDRTZHNTVDcnV6Z0xyd2Vsc290ck1ucjFoQlAzV3NtbTVxMUFmU0tFd21u?= =?utf-8?B?TC9qbVhuMnowRVRnTnBkWkh6OWY1NmlUWGMzSEliU2s2NkZvekV6R0FPT1FR?= =?utf-8?B?Z0JKbXdSOVBNdmJGNGs5dnhOM0dDSGZTaFdMMHRUaHlGeDR5MTBwWlI3QmtG?= =?utf-8?B?NGN5R25pdUR0YWEyT0w2Mnp0dXQ4SnQrT2ZvL0Z6M0ZMY0c3anc3eGNLQmhi?= =?utf-8?B?OHl1dkg4NUpSc2tBOXBoMzM4VE9BVk02UTFRWXRUdHRVaTlxZjZpODZ4c01x?= =?utf-8?B?eU1oZmpZb2FOSnBrK2gwUUM0Mlk3YUUrcGV3VjZ5VW5wMUJLdS9zOG1zaWtQ?= =?utf-8?B?c2xiUEJTaHg3Wno0ZUdXa2pOSjdUbmM3RFFsTW04TkQva05abFVuQndyNk44?= =?utf-8?B?QWlDT2dTc0pzd1U3bnNnNERKRUZBTXkzSG1ocXh3T0xXSk9kdjU1K0dSUHVj?= =?utf-8?B?ekowcVlQSzV5UVloaDYxR0ZhMDNjQUdkQTB6Y0RHQ1JvSytrWnF0UzYwbGlC?= =?utf-8?B?bXBkeVVuQkJRMnEzNjR2b1Y3UklxTXN2bmpXTWttNWZaVmx6RlBNUlpWUVd0?= =?utf-8?B?SFdLejBiaDBFWWtQMHBFcE5QSFY3aTd3Zk9qUVJCQVEwK0ZJL216YXJtZFI2?= =?utf-8?B?SXRzQ0FvdVR3ZTlRekFPK2VKa1QxMzErNlRXWXFKRlhQc3NrcWdibkF1N1d2?= =?utf-8?B?U2JFOHJkWGRYbjVsVjk0U1J2VHByV2N5TUNxUW5WcVhyYXhNbFdGYklGZzIr?= =?utf-8?B?ajJyVTVMR2VwY0ZUaGhTNkZTZ1Q3Q3B4WFZzNzhhVWRPbzBFd2xMRGMxdkdB?= =?utf-8?B?VmlyNmV4TWxsaHpRemVwUEtYNFdTWGp5VWNUdkZIZkVueGhUbWJEMFlNM0dk?= =?utf-8?B?bk9JOEphMVFlU3VZa0tYUHZqSzMrbkhuRkRGV3pwS1VrWnc3Vi9Gd1dQN01Y?= =?utf-8?B?KzRqWGJuVDhUNUxJN2RTR2dwUHlla3NNRGxvZ2J5NTA2eUY1aDBaUlJTb0JI?= =?utf-8?B?WG1XVlI3aTVBWFk1ZkUyYWtkQldpbWlIV3hybS9PNXA3dThHSFp3a0pCWUkv?= =?utf-8?B?YVR6TDBDeDVNOHNSb3BKbzdKUTIvL3kvWDNRYjdYa1VoaVRLNGFzajVmVGxz?= =?utf-8?B?bW9YNzVaQXplS1hZdjNLbWlUOEo5RjE0MlhsNmNPMDcrUVFha2srakNxNGxz?= =?utf-8?Q?sfsH+XTJMTmtNpMw=3D?= X-OriginatorOrg: fb.com X-MS-Exchange-CrossTenant-Network-Message-Id: 86c4b90c-a381-489c-2549-08da3d9f018c X-MS-Exchange-CrossTenant-AuthSource: DM5PR1501MB2055.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 May 2022 16:03:56.2652 (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: L8nmhdjE31ETA2ak8RDu7dyk09tcAMkFgBHgjGjvU3MiIFyBNU1D6LMCg6LvfvQd X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR15MB4026 X-Proofpoint-ORIG-GUID: xWimrXyBApEzy3uF_AV1wrYFb8LdVlfd X-Proofpoint-GUID: xWimrXyBApEzy3uF_AV1wrYFb8LdVlfd 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_08,2022-05-23_01,2022-02-23_01 X-Spam-Status: No, score=-4.9 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 16:04:05 -0000 On 5/24/22 8:53 AM, David Faust wrote: > > > On 5/24/22 04:07, Jose E. Marchesi wrote: >> >>> 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. > > Hi, > > Thanks for checking this. I see that we probably cannot use the c2x > syntax in the kernel, since it will not work as a drop-in replacement > for the current uses. > >> >> Hi Yongsong. >> >> I am a bit confused regarding the GNU attributes problem: our patch >> supports it, but as David already noted: >> >>>>>> 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. >> >> Note the example he uses is: >> >> (a) int __typetag1 * __typetag2 __typetag3 * g; >> >> Not >> >> (b) int * __typetag1 * __typetag2 __typetag3 g; >> >> Apparently for (a) clang is generating DWARF that associates __typetag2 >> and__typetag3 to g's type (the pointer to pointer) instead of the >> pointer to int, which contravenes the GNU syntax rules. >> >> AFAIK thats is where the DWARF we generate differs, and what is blocking >> us. David will correct me in the likely case I'm wrong :) > > Right. This is what I hoped maybe the C2x syntax could resolve. > > The issue I saw is that in the case (a) above, when using the GNU > attribute syntax, GCC and clang produce different results. I think that > the underlying cause is some subtle difference in how clang is handling > the GNU attribute syntax in the case compared to GCC. > > > To remind ourselves, here is the full example. Notice the significant > difference in which objects the tags are associated with in DWARF. > > > #define __typetag1 __attribute__((btf_type_tag("type-tag-1"))) > #define __typetag2 __attribute__((btf_type_tag("type-tag-2"))) > #define __typetag3 __attribute__((btf_type_tag("type-tag-3"))) > > int __typetag1 * __typetag2 __typetag3 * g; > > > GCC: bpf-unknown-none-gcc -c -gdwarf -gbtf annotate.c > > 0x0000000c: DW_TAG_compile_unit > DW_AT_producer ("GNU C17 12.0.1 20220401 (experimental) -gdwarf -gbtf") > DW_AT_language (DW_LANG_C11) > DW_AT_name ("annotate.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/annotate.c") > DW_AT_decl_line (11) > 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 (0x00000045 "int *") > DW_AT_sibling (0x00000045) > > 0x0000003b: DW_TAG_LLVM_annotation > DW_AT_name ("btf_type_tag") > DW_AT_const_value ("type-tag-1") > > 0x00000044: NULL > > 0x00000045: DW_TAG_pointer_type > DW_AT_byte_size (8) > DW_AT_type (0x00000061 "int") > DW_AT_sibling (0x00000061) > > 0x0000004e: DW_TAG_LLVM_annotation > DW_AT_name ("btf_type_tag") > DW_AT_const_value ("type-tag-3") > > 0x00000057: DW_TAG_LLVM_annotation > DW_AT_name ("btf_type_tag") > DW_AT_const_value ("type-tag-2") > > 0x00000060: NULL > > 0x00000061: DW_TAG_base_type > DW_AT_byte_size (0x04) > DW_AT_encoding (DW_ATE_signed) > DW_AT_name ("int") > > 0x00000068: NULL do you have documentation to show why gnu generates attribute this way? If dwarf generates ptr -> tag3 -> tag2 -> ptr -> tag1 -> int does this help? > > > clang: clang -target bpf -c -g annotate.c > > 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 ("annotate.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/annotate.c") > DW_AT_decl_line (11) > DW_AT_location (DW_OP_addrx 0x0) > > 0x00000029: DW_TAG_pointer_type > DW_AT_type (0x00000035 "int *") > > 0x0000002e: DW_TAG_LLVM_annotation > DW_AT_name ("btf_type_tag") > DW_AT_const_value ("type-tag-2") > > 0x00000031: DW_TAG_LLVM_annotation > DW_AT_name ("btf_type_tag") > DW_AT_const_value ("type-tag-3") > > 0x00000034: NULL > > 0x00000035: DW_TAG_pointer_type > DW_AT_type (0x0000003e "int") > > 0x0000003a: DW_TAG_LLVM_annotation > DW_AT_name ("btf_type_tag") > DW_AT_const_value ("type-tag-1") > > 0x0000003d: NULL > > 0x0000003e: DW_TAG_base_type > DW_AT_name ("int") > DW_AT_encoding (DW_ATE_signed) > DW_AT_byte_size (0x04) > > 0x00000042: NULL > >