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 DC3ED385E45D for ; Thu, 26 May 2022 07:29:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DC3ED385E45D 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 24Q3EklO029218; Thu, 26 May 2022 00:29:14 -0700 Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2101.outbound.protection.outlook.com [104.47.55.101]) by mx0a-00082601.pphosted.com (PPS) with ESMTPS id 3g9puan0du-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 26 May 2022 00:29:14 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MWf8RhutPYq/7a6oWGsHUvvSxplRpOHOFO0LCNG8DJKVY4Jcdgx7aNv4ED7LOXIITKycqnTLmQbsBqi8XtXN2kk7ChycEQzBMSvLY/DPbAMPyujsvmpqam31iL8bo8wJqhuqmJsmrvnqekvCoD2t5fp67Ta3mcfh784Jd3z7o4V2Ta8MUC84RakfBs8xMmrxU0f42/zFv++lX2DI1Wh+HgBel/ICAD0+00nEgp1VIje9nG5aZ0jxJeXe4+Jd7Ace4OvtpR5d7u8QBaQ5hPMKG9Wl17VEIz9O7SyqAiWUbXvXp5CWcT8k16xUwm6p2nGTJqvH4ZRNmdKwVDBKejy5Qw== 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=IO3p7vmxUJNUo2Ji79Y1TJVE6tTX9BffIxYUyyq8xW0=; b=BMrbCHuKKYkNLr0YZVTzyktYae34l71opLhS9xC/CJ5wrReWKT+G+nhv7r9BfhHFM51jYJcxv29RZd0pSDlazGI6iv+iJAnyJNADsNVfynUKG311KxMipQPj4nS0cYBZNIUwIT3FcrJtM0z5sbhbXesP5+5IbDJbNJuyjiVzCLKFh6Wzmi/t+C7nszt8P/CVmLvTq7q0FOMOcVfY3HktAJf1TgdRZu5FraEIRyJqFWzDBdPc49lrflRkbZUXvTNaXubhnBgWAn7kzMJGrMMqCA7bXZJ6wZpTvr93SMq18JRtNnuENyFL5n3AoOV2sGXcApH0P3v3aEiDGCQknafH1w== 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 PH0PR15MB5239.namprd15.prod.outlook.com (2603:10b6:510:14d::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5293.13; Thu, 26 May 2022 07:29:11 +0000 Received: from SN6PR1501MB2064.namprd15.prod.outlook.com ([fe80::fde9:4:70a9:48c2]) by SN6PR1501MB2064.namprd15.prod.outlook.com ([fe80::fde9:4:70a9:48c2%7]) with mapi id 15.20.5293.013; Thu, 26 May 2022 07:29:11 +0000 Message-ID: Date: Thu, 26 May 2022 00:29:09 -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: Content-Type: text/plain; charset=UTF-8; format=flowed X-ClientProxiedBy: SJ0PR05CA0049.namprd05.prod.outlook.com (2603:10b6:a03:33f::24) To SN6PR1501MB2064.namprd15.prod.outlook.com (2603:10b6:805:d::27) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6bde309a-2565-472d-d25f-08da3ee96da9 X-MS-TrafficTypeDiagnostic: PH0PR15MB5239: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: IwIhipLiAOCeCVLpeWqLEIiaCDvCuArYCCtYOrRsGM/pcPEgmtAUGh0Wy/9/E0nyICNM6f91k7YzRWWdR//IYiH3i9bSMw9d28DLDK5X26OlXaKSLdugz00MVh/F6RsMHpoEq0DAuRlKba+3glXpX9Jq3pab4O2aaS4V5BW1EH3TP3Igi/fZBqVKcqbGtW2RAuYJ9yB/HE54u84dCtj1FuWbVoiwK3fMBosLrXt/H599hdN09TgJ9CExPS+XZuy1EtbsoMmzmZeS+IEDj/cgmrJ4K40c2VTRVSxugmW3XA/rv40KybYVgzKZHOWEbLJjXle21WPi9EXOcum8b3uS2ziqKHwB+VpC2MkDn+h9ADNCgSFSAe59vlIbONErPkg5AUfHV2yJkPqLR/swoYZUl8Q0XsxKc7VxVxgMTyB4ymS8MM7G7x+ZuYG6bGDU1hh+WVOrj4dwSJQb7sYqs04rgwaI/XJLY8Nv8uBCKJoZtzoehV/RGSgbxlqpZDk4K8O2QrfVmbQzFpnrNFnm7NggqszOtBbQXZWonrGOCvEx5RsqFF6WX0j1SKCqT0T+0NRwTSJdKxiYu9MzdzEi823Eyj1Q/LgxBFWGIM6WYzzln1n6Tx1sDsJpPISBfePmZ2J5hBC/25+DY12ALrgOtYITikseS2aFJaZyvzaHCZqRM7SLdkDD69rbzx+HPoSfGLr+TLXE/FrYt6N8sUo5xUOTyWtrvjL8L+IrvXKHTasDuS4p74jDo8BuPaFccPqgTRlOF43tLyNr1nFuq106Z28kPoJBHENgcS46fG4WfLiUO0VOyVkkjO2OIqFGY0ifrkqJ 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)(966005)(8936002)(508600001)(6486002)(83380400001)(110136005)(6506007)(2616005)(53546011)(2906002)(31696002)(86362001)(52116002)(30864003)(5660300002)(6512007)(31686004)(38100700002)(186003)(316002)(8676002)(36756003)(4326008)(54906003)(66946007)(66476007)(66556008)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Zys2TzZrTllZWVU1SG9KMkV5eExock5RYlBzOHpOWGhYTjgyeUt4OWdDSzRj?= =?utf-8?B?UURxTVZFQVJCdFJoMEx1b09yZ0tzSXdDb1RyYjcxdE45KytySER3SmVVU0FB?= =?utf-8?B?T0hRSjR0a3EwV3N6NjA1b3ZEQzFiNjN2RVdNcFB2NkJyNVVkM0dLT2pHcTA4?= =?utf-8?B?V2JCYVloT3lGZDZlVUhKQUtOcXp2Mno1WThaQUZoZHE2ZXVvRWRkV2xINGNp?= =?utf-8?B?TFgxZkZzbWpUWjJUaFhXaHBjSzRHS1IrSzIzZHJ1elBHb0dlVnhwZEMzeW9v?= =?utf-8?B?Z0t6ZG1GTVV6dXlvY1hKeDRlNUUxQTVBdjljMklaSTU5ZHB2MXYreUdKbkE3?= =?utf-8?B?M0xtTXgxcUJaTVNHcmN2RXVRSUF2U0tmaGNDR0FxQUZFWFNyQTZzdzFPcW1U?= =?utf-8?B?SS9KSVkrUCtJWkF4MFFxbXN5RTZRQ2dPTm1JdDdBaEIxUGxKWm5hRlo1VUUv?= =?utf-8?B?dUx5dTJhNUhHVHI5bVVEMnBCMVF4bUk1RS9DOEU0TDJtQ3lqS0tTVHkraGU4?= =?utf-8?B?WERLZnVLb0crd3FLcGFLbnF3bUJJaEI2a0d3M2thdUJiWUl4bTNidlUvbzZC?= =?utf-8?B?NXQ3L1BkdlpLZjNNbW5RVGJvL2h3RFlsZ1RtcDVGUHpYZmwvUFB0SmtMeEIz?= =?utf-8?B?M2Iwd2R2M0s0RVJFY0Q1WTNCc2tHWTFWcGIrbTJJQXZYcHQ4dis4ZVh5dVVa?= =?utf-8?B?NmNMU0s0dHlEL1lFQi9HZVhjZ0xTV0xZVU9IRDE4SHNuT2NhRDNld1A5MVo0?= =?utf-8?B?NlNlMUtkaXBtMnRJeVpwZEhLNmVIelROYTRnS3lWSDRTYzFuNXZJYm9Bekdy?= =?utf-8?B?L3VOTkU5Y2k4OFdHWHJ1cEtVVXFDb3AzMXlpTDNValRGVE1LM0NtNUdKSTdR?= =?utf-8?B?c2ZGTkN0MTEzVjJMMzNQeW9wN2RyckhqUy95ZzFOMHE0TDRmR3RjeFMyVkJk?= =?utf-8?B?ekJaYVFkUmh4akNCRkJlcmdNUGRCZVE1OUNhSmVXbjRqTGJWVDZWZ2hjMkJN?= =?utf-8?B?RXFkK1FTTm9yUE9wY3ZZL2tBMHJjL01Ic201ckVjblJCNEtwSTVhbjhSQVhB?= =?utf-8?B?MFR3RUtNWWxXcXlWTzY1Uyt0WkZPdEs3ZTFNd2ZvQ1hiYU5UZk1qQWtwRHUz?= =?utf-8?B?cXB1TEtQck1VN0NWU293TERiWGU5T1hEU0dGT0ZvRzRmQ1dSbmNBWFV5Vyt4?= =?utf-8?B?QzVnSUJpWDd4dW03d0ZwTzFwWHArV2krS0lYL2NvUEdjQ2RwR0l1cVpmbEtm?= =?utf-8?B?TlNnNGZ3N3BJK1l4KytRLzZGeGw5bkY1bi9HQ3J0bFRoZWczdVRKWm1qMXBn?= =?utf-8?B?QURISklYaHp1RFY5RmVzRzI2VTB5RzZwdy9odjdxaGx4Q1J1WjhaUGxxZy9S?= =?utf-8?B?ZVdRenNPNEppWTVrVUJxbDR0ay9FZ04vV2xNTHFTUDk3dlAvaHFsS2JXNTBa?= =?utf-8?B?Z0g0N2FaeFlxUHlRd1lmVTdsVUJ3aElLTHpua3EwVFpIUi9RWnQ2YzVuUFV0?= =?utf-8?B?WW1zS21KU21sZEFwYXRjdGRySE9zV2x1M0l5eFhGWS93cFZuTThHeWxKbnRj?= =?utf-8?B?Ump3eUY0MmFZSFJLaXY0NitjM2tib0h1engvcjFIV1I3TFp0dlBsTXdFeGJq?= =?utf-8?B?dlN0Z0JvOEs5OEpRU3p5bFhiL3JsTW5KMXdwQ1EzampUTythZS84MTROQUt5?= =?utf-8?B?ZEVsc2h0M0kzNjl1eTVGSW1SR2ZIOStpSXBObk9ZTHQ5ZTQ0a1JqNjdBMFJk?= =?utf-8?B?b2pVd0RpNkFFY1NYY29GWWgyREdyazZqbTZ1RXB1VmlBbjhXRlRWYUJGZjVK?= =?utf-8?B?WWxGMTFtOEIrYXc5TGtzSVhYN0l1OGE4UGloeGFDV296M3pmbGpTZDdna2hx?= =?utf-8?B?bHhSc0h3RWhiakY4OVFoNDl5eE9NVkpjRkRLTWJaRitzVUM5SHBHL2hpWE1j?= =?utf-8?B?bmY4ejVoMWNFTHhVZzNTVGVIM2hDaUtwblhFYTRXY3lTMTFNK2syOUN4a0pN?= =?utf-8?B?T0UxSVRlMGNwd0E0Q1l4LzRQYjNMaU9MQWpyNUFkbExjanJFWm9tRk9NWG1t?= =?utf-8?B?VklCak9RSHNxSktZS3Zsa1dISlJqTHJtUUdiNEdmd2dzaENObVFmSUJlWHpG?= =?utf-8?B?UTNPYUVLQjFWejJDeG9lVDVjbTZDTDI5Z3J6cUQwZkNFMlQvVkd6cVlxTS9s?= =?utf-8?B?Y1QrQkpnVzVEWVFyQThFb2orVENNV1lrMXBHQWV1NkNIY1UwT081aWEwaW4w?= =?utf-8?B?dHRtSmd3TG1GUmZOOUcraktyZWpXZjJEY3NKelF2dlR2UE9aUEwxY0hVWTR6?= =?utf-8?B?bGZkSWNEQW9mOHpQRFZPYXlaTDdScVljemRtQ1FoeFUzc2tnR2NkaGZudENj?= =?utf-8?Q?B9Fpg9UWBGQW6w+4=3D?= X-OriginatorOrg: fb.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6bde309a-2565-472d-d25f-08da3ee96da9 X-MS-Exchange-CrossTenant-AuthSource: SN6PR1501MB2064.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2022 07:29:11.6681 (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: POH/wumzmRYZpm9YCwwCNDWSV/DWw59y10pqvAtR0eFKB7Oug9fJwX26+9q6nlum X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR15MB5239 X-Proofpoint-GUID: G8ZrGyHbBkzKMHgVpcjpXQHX7oVLt9dC X-Proofpoint-ORIG-GUID: G8ZrGyHbBkzKMHgVpcjpXQHX7oVLt9dC 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-26_02,2022-05-25_02,2022-02-23_01 X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, 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: Thu, 26 May 2022 07:29:20 -0000 On 5/24/22 10:04 AM, David Faust wrote: > > > On 5/24/22 09:03, Yonghong Song wrote: >> >> >> 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? > > Okay, I think I see the problem. The internal representations between clang > and GCC attach the attributes to different nodes, and as a result they > produce different DWARF: > > !5 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !6, size: 64, > annotations: !10) > !6 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !7, size: 64, > annotations: !8) > !7 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed) > !8 = !{!9} > !9 = !{!"btf_type_tag", !"tag1"} > !10 = !{!11, !12} > !11 = !{!"btf_type_tag", !"tag2"} > !12 = !{!"btf_type_tag", !"tag3"} > > If I am reading this IR right, then the tags "tag2" and "tag3" are being > applied to the int**, and "tag1" is applied to the int* > > But I don't think this lines up with how the attribute syntax is defined. > See > https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html > In particular the "All other attributes" section. (It's a bit dense). > Or, as Joseph summed it up nicely earlier in the thread: >> 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. > > > Compare that to GCC's internal representation, from which DWARF is generated: > > type type > unsigned DI > size > unit-size > align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff743f888 > attributes purpose > value value > readonly constant static "type-tag-3\000">> > chain > value value > readonly constant static "type-tag-2\000">>>> > pointer_to_this > > unsigned DI size unit-size > align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff74f87e0 > attributes > value value > readonly constant static "type-tag-1\000">>>> > public static unsigned DI defer-output /home/dfaust/playpen/btf/tags/annotate.c:10:42 size unit-size > align:64 warn_if_not_align:0> > > See how tags "tag2" and "tag3" are associated with the pointer_type 0x7ffff74f8b28, > that is, "the type to which g points" > > From GCC's DWARF the BTF we get currently looks like: > VAR(g) -> ptr -> tag1 -> ptr -> tag3 -> tag2 -> int > which is obviously quite different and why this case caught my attention. > > I think this difference is the root of our problems. It might not be > specifically related to the BTF tag attributes but they do reveal some > discrepency between how clang and GCC handle the attribute syntax. The btf_type attribute is very similar to address_space attribute. For example, $ cat t1.c int __attribute__((address_space(1))) * p; $ clang -g -S -emit-llvm t1.c In IR, we will have @p = dso_local global ptr addrspace(1) null, align 8, !dbg !0 ... !5 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !6, size: 64) !6 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed) Replacing address_space with btf_type_tag, we will get ptr->type_tag->int in debuginfo. But it looks like gcc doesn't support address_space attribute $ gcc -g -S t1.c t1.c:1:1: warning: ‘address_space’ attribute directive ignored [-Wattributes] int __attribute__((address_space(1))) * p; ^~~ Is it possible for gcc to go with address_space attribute semantics for btf_type_tag attribute? > >> >>> >>> >>> 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 >>> >>>