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 E4B163839C67 for ; Tue, 24 May 2022 15:52:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E4B163839C67 Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 24OAN0Ee012303; Tue, 24 May 2022 08:52:51 -0700 Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2169.outbound.protection.outlook.com [104.47.55.169]) by mx0a-00082601.pphosted.com (PPS) with ESMTPS id 3g6udnsjk3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 May 2022 08:52:50 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J55MxYiqnGEKFBkJ6GE/eeH5P/I7ralT/ARsYthdPAMYwqp+KdaV/FaiN41rCdSWxzpWFeNCRNzjsWzQJVXeYKOwgILi+r1X1IeQULeJWhzJwg3gxgsmvC9h01p1AsqxB2x/gJDMdKH4doKiIm4U6basjMwfV95ekSwnSQYfMf5hYNynN7ziTacRCU8N0LyXEtwHU7TSAa4l4LrHF+2p8f67/6dtEM6hXyMwi3f8ieGw16OukZs5cwwIeL1RoLOBMZpEIhnSNWnf5wJ+FIHJUDlUnr7OUizLVltPGxwww4NicDaBtHEN4i+PplhV6gOa6wj5nUf4rVBwJnc9N123cQ== 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=1kP5sxSQ2pn3ekoX2UMhnWrKwRSf2QTaYZu56ylPwNY=; b=IZ3oG51uIq1+VHh2gw/WAvXrvUXI6GHTYPn8B+K3xD7tmmngqbLf20lTneeDgNX2Keo1OnU1NI15dLW0Wn2mK/1HUqvNOoT/zMyoq++nctTCkJQAisWyd8i6KMhtSw3I8YErU8VmtcL1rzwZeD5vxjD9lpYkKDquON4invUkFC/52R8BcnAr6+HL7PetqGvzT0E8QautRDuhMnfGWLCVRDJ0J/cn/2N5FJUybFFJQamlDHuudQ/lCjHLsDcTSbFagXmp3lhxT6jiKCKdmXlweK9JrMeYSx7LNyaCyYNTy7u0Hq1oolVfyLzNF5VsnApAdrOzaZmZZpByz2DFzou2bw== 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 MW3PR15MB4060.namprd15.prod.outlook.com (2603:10b6:303:4e::13) 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 15:52:47 +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 15:52:47 +0000 Message-ID: <1ab1f937-360e-e656-f968-5f796f668ac1@fb.com> Date: Tue, 24 May 2022 08:52:44 -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: "Jose E. Marchesi" , Yonghong Song via Gcc-patches Cc: David Faust , 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> <9ec418b0-b002-085f-fc89-5a05fc3cd3c4@fb.com> <87h75fxk80.fsf@oracle.com> From: Yonghong Song In-Reply-To: <87h75fxk80.fsf@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-ClientProxiedBy: BY5PR17CA0057.namprd17.prod.outlook.com (2603:10b6:a03:167::34) To DM5PR1501MB2055.namprd15.prod.outlook.com (2603:10b6:4:a1::13) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ef4c2e94-f05e-4753-cf95-08da3d9d72b5 X-MS-TrafficTypeDiagnostic: MW3PR15MB4060: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: yqdeZrbz9bYxDxwCAJIkwxgS4rTphm9aZ1R7hkmqaMU3qEUhtUIB80t0RiU8gxXaZylDADVdTDVNZo2ZObAt65x94Q5r5DqoGOcn0xwCp32t9oXfI18CtoJjWGNh1kiuPiC48qDbxSEqYv5OUeDCMgNNM2dsDq7F34rMFK3M5ndvPTAKqvai9AdZs+wFUd4katXxeNVjNQcgO+giCGEO6N52Hnrn+WgZujSMO/jgNnqwWgZFX/b0WGjciKn4w33LysyfY9JzWCHDOx2/e7kN92Vktonf9hnMjHaQh7Qtcxo3cm2+maCtWfWr/Qkde3p6hJV5HE//kD5g4YmWGqG/5+4Lji989Nm0/7+/c8JmavntK+H2JeZTljA/dP6AeCyxkW+LnMmXbZ7OL6PYFN8vtzRXi1gkCPcHfcrd2kpVIHtQGv9ckGwtM5pFIhWOhB+oK6x/NWiquvmo37RNxsBoKKiZgF023uQuD+YLEueDXAO88yk/9h8OHFuHXSlfbV4GpmkBeB5KyjApPYp1wkoeNowspDFZ02d8KhfReJtzpJgIiE3pKik2jp5DWJ7Z5OdctaaSaUyZS7gOwIMdL3s/vPE908PW7SSiGSClgbJNpTBmQtvmGYISk4jkzUimRC42zsm/zs7uDNfbm4riZiIFvNfdqZYbv2aabKgGE1Ub64wBy9dYKeOoIHjytVhf8Z2B+4vDu6bF7WXENWVlLhC7mkrtJxt6W1U/3vfRrthmeAHzMtZDExlnX+qEEIostP/dTs/JzBXLfwL2b40kBkggahPAO7bCaLmqRxc2Snvk/VVJDw/BsxC5jEIbSbRjQ0IX 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)(30864003)(31686004)(8936002)(53546011)(6506007)(6666004)(52116002)(4326008)(8676002)(6512007)(66556008)(66476007)(66946007)(36756003)(110136005)(6486002)(5660300002)(966005)(508600001)(38100700002)(2616005)(186003)(83380400001)(54906003)(2906002)(316002)(86362001)(31696002)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Q2xDVUVmdTVDbkRNeGQwSUxJYlBUMjcxa1RZK1liQ25TcnU2UzhDd0RKb2x3?= =?utf-8?B?SjkwSUhJejdpYTBqODR1NTFmUW1MSzd5dWdqazZISmlGSVpQWEYvbjNIL21D?= =?utf-8?B?a3N2NHNuQnc4dmhNKzdZNzltN3BnSEdDejNMZ1dXZ1JnVjdzUm5VQTlLNXBR?= =?utf-8?B?WmRMOTZ4S3lmZWF2cDNDaUhKRjFlaFpwbWtaNTY3Q1FMTTA4L1M0VHI2Visz?= =?utf-8?B?SGpjbUR0NTRwUWZRMjh3WmQ2V2NTUTgxN0J2NDBSU3Z1cDhqemxwVW1xVVQ1?= =?utf-8?B?ZDR3c3VQckdCNWpvNHJ5TElXN2c5YjlRN2ZvSERsY0lkNDZMc2V4Z3E0Lzdk?= =?utf-8?B?TzRwZUFrSGlnOC9CZmtUZHUrZHFSK0U0WHRtc0I2MldqTytlR1FOaGoycHBk?= =?utf-8?B?RE9DUHVxbVI2LzFtalBVam5tbnowYlY2RkFFTlliUm1GTmV2NjAwcmRSTGQ3?= =?utf-8?B?ajBuY2szbHM0V1F0NFNLQVhrbXlEL0FtWTNDM0ZMQWE5cUdmektxcklwU0ZO?= =?utf-8?B?cXJuMFVOVGJsNXZXZHY4NkRrVk1xSm0wZGtYOTJnTDRhMi9JS0lHc3cxSXk0?= =?utf-8?B?dmxMN1UrakRGOFdNaVpKa252QXpYMnJuYzEzN3p1Wlc0aXRGSk9lRzVoMHZM?= =?utf-8?B?ZC9TbUpKSnlFOWQ1OGc3UjRQeHR1QmtSL3h0M2pNNlJuQTU4MjNZV2JvUHl5?= =?utf-8?B?M2VnSVUxRTNaeUJkVFR4UXc4Nmo2cFZ2MzczN0Z3NU1qZXF5QlZqeUQ2RVdD?= =?utf-8?B?SGhzQzF1amY5MWVNR0E3RklNMHFKeGxUZExWeGNHazVvL0IxQU1HcFFDVG03?= =?utf-8?B?Ly9TcE1nTWx6SFpFYTdBb0RvemRGbWpQTXpLbW1GM3hwTW1oK0tIMjJuOWF6?= =?utf-8?B?Tis0WGVlanlsMGJVZTQzQXo5K05oUndmNGoxV283SHRkMGxkbTJoNytjUnRC?= =?utf-8?B?RlU4NGFrKzYxVjFQNEhjRWFybUFGTTg5VWN6QXpPdDY0ZUZpejQzZ21HWGxa?= =?utf-8?B?T2dvQkRnMGV0VXlkdkNQU0VuYi9NYVlBVXNnQUFMSlg1UkFKajZUV1kxRE9I?= =?utf-8?B?Z1FPRHZ5ZDlvQTJZN2RVMnNidk9FOG1lZUI1TVZYYmc1QWdLcEg4dHIrMkRD?= =?utf-8?B?ek1YdytEdnkwbXNnM3BWR0w1T3l2NXJzcW5EeWY2VnBMclY2MjZpenpZclhW?= =?utf-8?B?b25zeGFMeVd3czJVNGhWK3pFd1RVN3JlcDVaR0ZERWticVFlaDh3NkdHRnFI?= =?utf-8?B?Wnp2UnM5SXFRVmFXai8zSEtDakYzV2pySVJJdDVsaUxVMFUxeFhkSkhSRy9v?= =?utf-8?B?TnIwTE42MkxqazZRSmFxUUlFSk15dkZsOWV5NnZVTVVPbXZyaUxHOWpQOWxq?= =?utf-8?B?UUNKS0F5Y0JKQUxDVkwwOUd5MHl6enVvY0VZTXVqOW5kSTJuWUsvVW9CVnZD?= =?utf-8?B?M0NDb29mc25oVTM5Q1Y4SjgrbXZpZldoR0dmV0gzUHgrUm1ZR0xtZEMxN2My?= =?utf-8?B?Z3Y3TDNTeVc1ODFNZmVIeW1OUm03dlBjQmJCakR5TExkdmVXZzRnNFZQNUd2?= =?utf-8?B?bEFOcFF5cXpyTFd0TjVSWVJYRzY1NHY5Uld0YzhwZVlHWEdOQ2srRGZMdHhY?= =?utf-8?B?NFNxOFlWNVlVakZFemhLZGFxd1lqQUNVdjZvcmE1SVZDNVpndGZ3aFQ0a0Zt?= =?utf-8?B?OVYwQnY0eGNhTEdUN0VCR1dsRExlK1Y5UTZQSUppSkJINUt5QjZlSGgyQnFH?= =?utf-8?B?MGdHbGh6dnZ6K0FCKytaSEV6SWI2cm5EcG9wQW5ocDBUVFhPaEVmcDMrRWRr?= =?utf-8?B?SGVtMmJPQ0RuWHJvRnpaeGw0YWNsN1pabE1DVWNxZi9kUFNVMnIxNndPWmk2?= =?utf-8?B?WmVCdkNZOGt2NXdybDhySlJjMlNXNHMxeFduNnduazJuMkRQNFBCVGpuclB2?= =?utf-8?B?Z0pCVlQ0VFRnZTlIQ0NkcFlzblR2Sk81R0ZJWHVRdnBLS1BkOU83eTFPTFhy?= =?utf-8?B?QXBBcytwU2s1R1ltbWUyOEJCeDlEdnd3eDE1ZHoyOEpiTE5uSmVBZFVDL3Bv?= =?utf-8?B?T0krZ0pmU0kwNndsRndsVDhHUVgwUHA2ZGhoemRxWU5NQWt2VlJoc1plMFpN?= =?utf-8?B?TzdEOXV1MkJiWktPSUdobnpLTDlFS3llODY4d0xsZnl4ckZmeHFOOXdKT2Y3?= =?utf-8?B?eS9JN2lwckVXeGxQZnpUaERuZFdXQ2pSSVdSMld2T3pmMjlHTGRFRXFyV2tE?= =?utf-8?B?WmM4VTNucDdnd1BnTHNVTkVKeGgxMmV5cUJYUjVtZ2swTDBCYUdsVjlZSUZZ?= =?utf-8?B?bmZPMmFIbzYzWFRSVC9JZkkxUXRhMXF5ckZsdDZNaDFYbG1raGp2K0JrMmNj?= =?utf-8?Q?Q5jMtMEw0McR7mfQ=3D?= X-OriginatorOrg: fb.com X-MS-Exchange-CrossTenant-Network-Message-Id: ef4c2e94-f05e-4753-cf95-08da3d9d72b5 X-MS-Exchange-CrossTenant-AuthSource: DM5PR1501MB2055.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 May 2022 15:52:47.2367 (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: e3PhNIvc54hKp1MTm0e5tUy9jP7NxMljlIFfVHx+KNst7hWZ4Q+yW2bKhlvUkz5a X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR15MB4060 X-Proofpoint-GUID: kjgQxZmv-eT9pJFF5YMb0HF5sBgX6ZjA X-Proofpoint-ORIG-GUID: kjgQxZmv-eT9pJFF5YMb0HF5sBgX6ZjA 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.8 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 15:52:56 -0000 On 5/24/22 4:07 AM, 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 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 :) Okay, for #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; As you are aware, clang generates IR like: !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"} As you mentioned, yes, we put the annotations in the pointer itself. This is a pure implementation issue. We could generate ptr -> tag3 -> tag2 -> ptr -> tag1 -> int type chain and encode such type chain in dwarf as well but it could make existing tools hard to work with new format. What is your proposed dwarf format? This may require to add a new TAG type or you have a way to use existing one. I think clang can change to the new format as well if we reach agreement.