From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by sourceware.org (Postfix) with ESMTPS id B42173856DEF for ; Tue, 7 Jun 2022 21:42:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B42173856DEF Received: from pps.filterd (m0246632.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 257IDmff005933; Tue, 7 Jun 2022 21:42:40 GMT Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.appoci.oracle.com [130.35.100.223]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3ghexecbd0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 07 Jun 2022 21:42:39 +0000 Received: from pps.filterd (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.16.1.2/8.16.1.2) with SMTP id 257LeTti025686; Tue, 7 Jun 2022 21:42:39 GMT Received: from nam04-dm6-obe.outbound.protection.outlook.com (mail-dm6nam04lp2046.outbound.protection.outlook.com [104.47.73.46]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com with ESMTP id 3gfwu91cxy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 07 Jun 2022 21:42:38 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FSgEJnVY6SWxBQiVfl0Hs4ZswRbHQo4+Svn6rOU+q17cvqBlQTk4J0Fxsod6EKBw0NqIb+pmtTAWmsTso78NvbmQpuKvTLULaRO+1nLhWbcHS6pxKkz4GShuYcJFTn17Yz/18xrh3n3wFwbNRiBNVS+zLWa4dhVY7Go4x9+eEwFGnBgDvHs4SkFaRvFQGNinTYmZF4dx2pH6li6mB3jirD7P5Rt0paEpZayJQCssjJiDbnEyZKcPHTDshEcGxuB9ZPgf11seuHdqfHu67x67+E6Ljm4GyKw8HfEUyWnGrmMvNd1TPgwhszFe/ORYFbaOcsCZnMEqYrKOlt808QiCjA== 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=rqyjZxO4aqOxFLVciJRuHlPt27R/zVrb3+90L13wqdo=; b=V0PT76oC+fl8zpKQPQ34gr3lz1x3lW/TbXiAl3hkTviEnnnOp8pZMZgo7gL+qWr5v1byG0xv7BwEJi7vv7MRM/hdExnEE1b94VQTWg6Dv60352kkYkW5o6ScyzjCcgtvCkMMaRttJ1UMWkRvsbBgqQEptOMxSpRPLIjsQ+yrnUOz1e9Ek8piI//LZgKu6uF/WwEUmh6u6K1Nokq9s2D1WGj3lzKJZs5jSUlv+vDttfoQcvHCt1jZ0mQRSRod+RX34h5oA6rU/2h35G7ZdGx2jSmPxSdEaWP9uZY7818xbX+SjWmQ2teVMedy/DQjvAkLCIU51euknfC+R4sx+bVVBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none Received: from MN2PR10MB3213.namprd10.prod.outlook.com (2603:10b6:208:131::33) by BN6PR10MB1522.namprd10.prod.outlook.com (2603:10b6:404:45::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.12; Tue, 7 Jun 2022 21:42:36 +0000 Received: from MN2PR10MB3213.namprd10.prod.outlook.com ([fe80::4939:15e0:57cb:87fb]) by MN2PR10MB3213.namprd10.prod.outlook.com ([fe80::4939:15e0:57cb:87fb%5]) with mapi id 15.20.5314.019; Tue, 7 Jun 2022 21:42:36 +0000 Message-ID: <49e6e6bb-8071-dfba-38b5-be5453b79538@oracle.com> Date: Tue, 7 Jun 2022 14:42:33 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; 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: Yonghong Song Cc: "Jose E. Marchesi" , 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> <0cb066a7-ba9c-123b-d55a-58667073543f@oracle.com> <3be9e5df-e74a-bca4-2fa8-f865c4da525b@fb.com> From: David Faust In-Reply-To: <3be9e5df-e74a-bca4-2fa8-f865c4da525b@fb.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SN4PR0501CA0035.namprd05.prod.outlook.com (2603:10b6:803:40::48) To MN2PR10MB3213.namprd10.prod.outlook.com (2603:10b6:208:131::33) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ba9c6b86-658f-44ec-f588-08da48cea317 X-MS-TrafficTypeDiagnostic: BN6PR10MB1522:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: wqk/gTWGzObmBesK7lIWlmfQlU4gfjmkcDg3n3ZK03A7m6ExBWQa7xg2cAPb0e6msTXA5PTx6dCKJDVA8poPy6eJYHtwAQW+x53EigSP24XMKL4RF/xksVehow5Zs36A/Mdpaji/0KQCgxJZjILDpYIW5RMt96Tk2+6K41izD8neARNNU3J9dZ99C1cHZuqEjlXXyQNVdBB/mWxqT2b9KsQYLUu90HDcTyxfE1amaB/jmZDtUPWSXxAQRMYkSMBe+3pjZR2J+aev2453Z48k0LF2x+W6gZ4dUEjdnUOih/15hq2RIs1NVd3az0Be+5hMufOLfINV2NmuOlcmzmDo22QDW0xIOHP0OYJKH+isOZkqZJS2Qvk4SBiMlF7hiLRnV8BUpWjwchesZ15bdol58IWeUEOUdo4kxzedXD6dTFSa6T5A0qamAGweHnDFVrywvrRTtrUX8g5DroCs6oAsmQfC8QqVCblydnBobrdg57dTs+1H7tv/MEGhz5tvJOrhYYfbd9Osb7ew+feTXFzOdFfBe1gq7VXPFsWrmw9wmOigEHMG/CIjivQZFhp1uH0C+jUzs+uGio8qdNMWNIW6+5KRw04FcK3Ihh779uFiXqRzbx94ijQB/wkWcIRLKqX9TTesILaaAYHFNmYHnhjcbj/xQj8qX5igpeBz9xl9sc01yHCsFfH7ZE8/W95ljgVU5tFFkWFDdaiGDB9Xb61cq8IisHRuoYu2Xr8y45QQfeFCv+VMGnUtSKB/mAW1owZopz1Wzi8e2Puabri+N8o24BlJkqe1xcrO1S1snEA47AzdkEzRjGmyB0QflopMvBVHPsaaTi280dmcGf4bjHaooHA0x6bhxLtxwC7WgS7z3Hw= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR10MB3213.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(36756003)(2906002)(5660300002)(83380400001)(6666004)(38100700002)(6506007)(53546011)(6486002)(316002)(966005)(8936002)(508600001)(8676002)(6512007)(6916009)(54906003)(44832011)(66556008)(66946007)(66476007)(30864003)(4326008)(2616005)(31696002)(186003)(31686004)(86362001)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?N05OenVDL3g0T0MrUjZTVFhkTkdSSU14YVp6Mzk0djhkcnFibWJjUnlZQzAr?= =?utf-8?B?OFZsUFBKZ1FJd3lkRHFYSlYyNElWakEzbnMwZWVUSEJSaXdsUFBrNFIyVkgw?= =?utf-8?B?MkFocFJIVE5SMkt3cGxtZjMrWEk2aDdOLzdlT04wZkt5YnI2ZjlUTjN4M3NN?= =?utf-8?B?WmY4a01zNVhpNjY4SFY5MGRraUdnM1F6aERKaVRqcmRGa1VkK1BaMFYzczM4?= =?utf-8?B?L3IrdGdxbnJpZVpEcHBqeVRXTHJxdCsxcUc3OTdqU1JqMW1rRmM1clFvUWEy?= =?utf-8?B?OWVKZis1TENhMlM1WVhtVUI1UVNpQndLREZCcVo0WlZQVXdXdGpYbmg1RW1v?= =?utf-8?B?ak9SN2tXcXFibUpuMzJCNWNDNHNUOW1Na25XZmZIcUFSUVpmVm5laFl0UDRi?= =?utf-8?B?SUkrb1hPQko4K2xCZk55dGwzNlRMRmZwY01iNm1MTm5IM1pFTjY3TXNQT3Rv?= =?utf-8?B?VGY1cGdGcmVwOW5ESHpkbzBjNHVSVXJOMllPWVZkTmVKdEFWN2NtR1E5Rnk2?= =?utf-8?B?aTI5aTdDQUJ0MVlwSnhsTTZJTGxtOS8zNngzR2J0eHhPWHFieVhYN0VOWFZK?= =?utf-8?B?eXBFSlZBRERXNW9Wc21BbTJPQ1JnSjQvWGswNVUxS3pmNEVIVkV1L21GS3lz?= =?utf-8?B?RFFTYi9Sd1Z2enpWZnhxNk1QODBjRHBCMEZUWHppbFBYcjVudVhzZUFENFN4?= =?utf-8?B?bzUrTTZMRURveEVtcUVZRUkwSGlsUkZ0NU1YSkYwYjlOd0sybk9GUTVlRVZ5?= =?utf-8?B?d3h6UktsNllEL0JpVGF6dkJhU3pBempSZ0hUSFFNZmNVRVNYanJ2OGhyRDRk?= =?utf-8?B?ci9zUW5lRlZsNjJKRndpeFgzakFraWE5b1MwNS83RzNrZEpoanlpQzU3dDl4?= =?utf-8?B?SHgzcUROTEI2TElGRFZwTS83VlR2WVQxa09ORDVoaG55TDVEckVwdjcvME9S?= =?utf-8?B?NzlIbGRhUUFEbVU5MjJuclV3eEZ6SWpaQ3Q2TENyRUU1WTlza1lJSW5USFoz?= =?utf-8?B?WElGbEFkYXloc3pSZkVKTk1kWjhiTEFYbU1HckJoV2xkbkRjUXBXNHQ2aDVq?= =?utf-8?B?NDVhZDdIYVJkWUdMYkVaZTVaa05yWnR1K21YUXZCVk1kMG51dk5YODk0MkRT?= =?utf-8?B?c0dsbS8ybWVwZ2p3TklMZnc4NVd5WjJMRUh0QVZGdHNkVUVaRjArWnU5NzNT?= =?utf-8?B?b09vQTIwSFRYUCtiSklmMDBiTmcyWlkxM0cwenpyQTFWamlpYnR5V3VPNkZV?= =?utf-8?B?MG0vNXRURFJLemhnTmtjaGMwZURPLzh4eDNOZ2RvcWpoWUUyb1JFcVQwU3Bl?= =?utf-8?B?MlFqZlc1TWhFUkduV3pqaE5yb0g5QTdBQlhBY25hMU9LTVdjZFZ6a0hpcVJL?= =?utf-8?B?a1I4WFNqZ2dGaUdycVBXMWxTNStnT0ZnZlNCaE1YbVNlMTNWOTZOQXUzMG1K?= =?utf-8?B?Y3A3TVFoNzl4U1hGZTlXVXFTV0tBaU5tWW00c3JqU05POXVtZWhhbEYyM1ZG?= =?utf-8?B?VC80bkhGSmU3MUxmUnl1UjFwd2R1MGxreUU2VTdxbVRaaHU3NmtEdGFlQmJv?= =?utf-8?B?WFF4ZzRFdWJ4bGxHWWhHUjNTdzFMdk9YWWY0M3kzdGJHemJHdWtRU1lBS21a?= =?utf-8?B?U29icnhXdk1VWmd5MTVTcENLTWFNTHdXRGpZa1J3M0ZBWXlnR0NwOGx6N240?= =?utf-8?B?N0JEUlltS3NhOWxTMmplRmtpYWdnb0dJM2pNMURRakoycEVRRHdLd04rNlBX?= =?utf-8?B?bTE5b1h2WW5hVyt6RE5PK2Z4RGRQV0hCSHlDcVo3UFdOQWV3M1BTWktvaTNV?= =?utf-8?B?NVc4QUpxRzd6WDFCSFpjMnZBamJKM09QanlSSnFUR0RSTmNCZXU5eVBpejBQ?= =?utf-8?B?UTE1ODlVbWN4Mi9OOWpicTZCUXFpUjFDY2M2ZDI3RkE0WElQSXdMYWtWb00y?= =?utf-8?B?NlgvSndjbzBkakgvNzNzQ2pIZHp3cnpUWVphSnVRZ0xkbjE0dTR6d056Mjhs?= =?utf-8?B?MkRIb0ZZaG5ZK2RzaVZkNDVwbDRDNktrQWxqL3B3MjZlRERqVlYyMXZwaFV4?= =?utf-8?B?ZGNKUlJ4S3NFaFNKQ1VZbDVweFEvS3FZZENTQUdteERGTTR3ZjRRblV1ejJF?= =?utf-8?B?Zyt2OFpvTFFlSUl6dXZydjd1bUN3bkZZWWdXR3ovejJQbjNscldQNkZNV09Z?= =?utf-8?B?TzRRcmdIQVhTZ2FuMW5Ja0hldWJhbWQzKzlERXhsLzZZTjUwNHZXY0FQeEg2?= =?utf-8?B?V05WUWo0MDhraVVqL3gxL2Y0NFJ1NGFLU1lETFZlc3VWTmpjOWw0MGxoMXNy?= =?utf-8?B?VzhDYXFYbkg1WTBUcXRjemNBQm50bWZuVEpqV3AwYXNxcnZlUVBUS2RyRVBR?= =?utf-8?Q?5Kgp/N8U7bjv3U52/29qWUI3+BinasAWey2uJ?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: ba9c6b86-658f-44ec-f588-08da48cea317 X-MS-Exchange-CrossTenant-AuthSource: MN2PR10MB3213.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jun 2022 21:42:36.4940 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: K6JYIjZrUjIrKk6zmglhGXFnxe90TXKwPKvFBO2YswENaEQyPLL6zOkME7oeQJxoHPyvTCWDh2ZAlkfOxnzORg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR10MB1522 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517, 18.0.874 definitions=2022-06-07_10:2022-06-07, 2022-06-07 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxlogscore=999 adultscore=0 bulkscore=0 mlxscore=0 suspectscore=0 malwarescore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000 definitions=main-2206070089 X-Proofpoint-GUID: xrqHB_G-EJDJ7tbm41dnworjLKWxJZzm X-Proofpoint-ORIG-GUID: xrqHB_G-EJDJ7tbm41dnworjLKWxJZzm X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, 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, 07 Jun 2022 21:42:49 -0000 On 6/2/22 19:04, Yonghong Song wrote: > > > On 5/27/22 12:56 PM, David Faust wrote: >> >> >> On 5/26/22 00:29, Yonghong Song wrote: >>> >>> >>> 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? >> >> In cases like this the behavior is the same. >> $ cat foo.c >> int __attribute__((btf_type_tag("tag1"))) * p; >> $ gcc -c -gdwarf -gbtf foo.c >> >> Internally: >> > type > type > size >> unit-size >> align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff74475e8 precision:32 min max >> pointer_to_this > >> unsigned DI >> size >> unit-size >> align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff744fa80 >> attributes > purpose >> value > value >> readonly constant static "tag1\000">>>> >> public static unsigned DI defer-output /home/dfaust/playpen/btf/tags/foo.c:1:45 size unit-size >> align:64 warn_if_not_align:0> >> >> And the resulting BTF: >> >> [1] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED >> [2] PTR '(anon)' type_id=3 >> [3] TYPE_TAG 'tag1' type_id=1 >> [4] VAR 'p' type_id=2, linkage=global >> [5] DATASEC '.bss' size=0 vlen=1 >> type_id=4 offset=0 size=8 (VAR 'p') >> >> var(p) -> ptr -> type_tag -> int > > It would be good if we can generate similar encoding in dwarf. > Currently in clang, we generate > var(p) -> ptr (type_tag) -> int > but I am open to generate > var(p) -> ptr -> type_tag -> int > in dwarf as well if it is possible. > The DWARF encodings are the same between GCC and LLVM. In the case we've looked at in this thread where the DWARF is not the same, it is a result of clang attribute parsing not following the GNU attribute syntax correctly and associating the attribute with the wrong part of the declaration. But this is not a problem with DWARF. >> >> >>> >>>> >>>>> >>>>>> >>>>>> >>>>>> 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 >>>>>> >>>>>>