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 A722E38387DE for ; Fri, 27 May 2022 19:57:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A722E38387DE 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 24RG9jQS001977; Fri, 27 May 2022 19:57:01 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 3g93ta0415-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 27 May 2022 19:57:01 +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 24RJaiOe033115; Fri, 27 May 2022 19:57:00 GMT Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2171.outbound.protection.outlook.com [104.47.59.171]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com with ESMTP id 3g93x80hpt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 27 May 2022 19:57:00 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UIDx0l3zDWmg2CaZGKjKX206Dt8ATLJe2s1+6H2x0i6cRvEPOQCffl0BMNhKC0q3XSV4ctw/HP/8lpt3mZO8StpbDFlO5d8EbMDDJd6bVBOLl7J6GRtQlhhQ0Tg4+O335cS5ipZXO/5/Zw10BPlCmXi2q8vZcFsuqaWOmTzbK7nbVQhR4mlm1WJXTxIZGUFdivrcmwAktqsTxCMgezcX6ALEUIt2TRlOkKna6OPAkHqBpkVP+FDYo60Pr04UwzPO4i9GoRrh6A0Cuy4UHD58TfR1V/ODmhmfrS4Das611YjXWhJBsBsW6cD+sDfduGx9vuzrEIBwNyLBRPgzWiQxtQ== 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=TokD/Y3fEzNmuS7P8MotNaZ9QNnMIwcMJJOpavBdicM=; b=cfzYl1uRQgrwdT0Lu8vfK5blrLyHtIfW6Mfvoz/74QiEEc2QTF14D4OYT3hzlghOMnfJr2lrgbgaxC7cThCNoPXVfbm5ROYabeT5RQz6TjDsrCQl5E9gBu9WYjUKBJEXZHHOqKDyDDaaeEcJMBRMGxEubtyTw8J8B+wUNIYajLS0C+RZA0rA5plJo5t2E/wq//AyGUk3dUzOWE4BYXV7lS5QupzkfGdgNOYL6LZlxjZtTGGUM86s/Jdl8v4wZLwqlAaV7eONZES2a9ePmD3T27KxRjxsDpkUg9YeCW/sE9eug7iTJnkMtrSqSIRC9lJpSyBxJIzykSAG7obwqTvirw== 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 BL0PR10MB2914.namprd10.prod.outlook.com (2603:10b6:208:79::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5293.15; Fri, 27 May 2022 19:56:58 +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.5293.013; Fri, 27 May 2022 19:56:58 +0000 Message-ID: <0cb066a7-ba9c-123b-d55a-58667073543f@oracle.com> Date: Fri, 27 May 2022 12:56:55 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.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> From: David Faust In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SN7PR04CA0100.namprd04.prod.outlook.com (2603:10b6:806:122::15) 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: 39a29dd4-6ad5-498d-b0d3-08da401b0e96 X-MS-TrafficTypeDiagnostic: BL0PR10MB2914: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: 8n6URZlzsfGWc1oRsMX8TMnbJJ03A6o9LYhulODt3sEUF788zfvdOQjP+9LVL5lifgmTu/2bC9Ul/v0VFV+ROSosIUylIDfnApE1yLjX50ab46w3/KgUssCxbem8B7FbLFiGkZ7eGtqBtW1RGCSFjOYnJzkOACjZILPlkmn0BsFfbVNNpykdTelJVMFLksXLtC88IvtNxaavwv0vwwfZklZfjdRVYW6JnLUiKCpoHR2qBi4J5fY70z3W8KrpMWC9Z3MTNLzeV5O7CLl6Hf00Ge0O80MCH6sUGeIVT/IEG5S1ZswzYgucI+scRFSnseGAi9BFe2ZeWrnDlOGvy025deYwGINIoqRGfxtnMx3V/TW4h4H1lilmvtUtURCSiq2zVhN/CF790X3A2yaHJWzhDm338qFWTPYWaxIwfMl4bUojY/bjTrVgbUIVOmuoVE3A+q6p73lMSWKYT7catTKFg3Y7xY4+tEr+q5aird9nugB2rqzXzyQOQDqdzsP8R0F+gmzZjfuaTs7QWSwRTg120J2AZ6yzqIoVKQNUOlSAx2ZnP9xMyQSA1O2flzVxMwETItdojClsCw6ngIEWPmmPiPRNMF10efb5GhTxRpLL9x92uOUthdBqvQqd/JI8xuXgLOxV1QF3mCsAdL8zj6BAfb0TNRq0X9QCpjQ84S7+jNtwpsPYHn5xeZKY2wDzP3CegWdzaHyVuhRL03GRJMuTJd92qE6NJagZPEgaV1Oub5fCC4ubz1Ikhlqz6exxX1Ic3Z59fRBs6nfHlshXm4h0bGS1pI4dl56w5uDEQElCOGUIOlHAZVUI9QPCgj1r3CSbnqi0OxK9IEMZFGEEb8aHwSvW3z9qToxClIUO7w7BGr0= 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)(2616005)(8676002)(4326008)(2906002)(5660300002)(186003)(8936002)(66946007)(66476007)(66556008)(30864003)(83380400001)(36756003)(38100700002)(44832011)(6506007)(6512007)(966005)(53546011)(6486002)(54906003)(31686004)(508600001)(6916009)(6666004)(316002)(86362001)(31696002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dHZiNk5xbmV2SXlpcmRrdVhDZllyREUrc2JXT0hyYWNUcTZ2QkJuNmQrNURp?= =?utf-8?B?Z0JJWHdNQ2VBK3p6T01heWFYemk2c29TeDFFVWRvdTB2WFViU0QreXdKeUNC?= =?utf-8?B?SEpTRVl0UkY2YWNxdzlIei9WK1d1ZHNIWGZrNTh5M25Bdzk3NUJCakwvQWFW?= =?utf-8?B?eTg5aUtIenFvdHc5bUd1OEg5OG1CUHl1NHR0dGEzc3JBS3Z2Um5DaWM5Mm9n?= =?utf-8?B?RnBzK01ma252bm1YWUVOaVQwQi8yS2UwS1hQbHI4VTljS2VjNmxjYWp5N2Vs?= =?utf-8?B?eWZNQVpORVhuazVFVU8xNkhtTEQwdHZkWkJlVmRoQkxwS0tYQ1hKYnE2Nisv?= =?utf-8?B?akNwUHRNTjJDN3pjN0JJWUpDZUp1UGxGemhnRDMwbjMvenBHTnVZcXJyRW5u?= =?utf-8?B?V3hOT2Z3R0RWVzNwV2ptVkdkSUlLekNhNXBNc0JDSVFJVzFpRmxmMlJUWlcy?= =?utf-8?B?ZGNrQzlpc2ovMXIzYlJBbXQySUxEcW16TkN0OGxRd2dqWmlYazBzYWwrQ3ly?= =?utf-8?B?K0diOEVULzR1R3VKM1Y3ZUc0L00rOUVtS1R3U09VenE3eDcrUklDblVSWUw1?= =?utf-8?B?WWpZYmVYUnpjTmZOVmo5MlA1bkYyK0NTUXROa0Exam9vc1dMd0dFMVRJbEky?= =?utf-8?B?TzI5T0Vka0VnTFduTnBHbzV5cmpMMFN5VDFTMEh1ZU8ybFpLRTFLdE5lZ3F6?= =?utf-8?B?R0RUUVo4Q01XSWNpVWlsTHZQYzV2NU5DYzFEUVlPZ3htdlhXbHpLYUR5R1kw?= =?utf-8?B?TVZvQWJWeEdxVzZ5RWVWdUd5Z1hTL2ZQam45TzdaYlovK2RnTWxMbDJzVnJr?= =?utf-8?B?Ym1Gem9veEduTmJNOVllRU50ZThCRmVVNGo5QkFBZlgxdHdQUUM5Vi9uZ2g4?= =?utf-8?B?dnpmZWFVQmN0QlVPL0RNZHZocVR2VGdkSkRjcW5Pb01nNVRicnJST2NFYUFQ?= =?utf-8?B?SjJKZEk4cWsweDAxRmFvRTgxa0VJNW1ZblFjVE5lVTc3SzJ1MithZ01sTVNm?= =?utf-8?B?eFNsbkl3L2V1dmMwL2NxT2s3NmM0N1pPN0FNREh5M3MwRXhQR2RmZUx4YXBm?= =?utf-8?B?Zk9Bb1RuMmpSUFU3SUcrMFVQRVRpKzNOdXVYNTJoY21pZXlYOXRQRHFVUEFZ?= =?utf-8?B?MzlMSUVGNmYzVm1vTjNMNTlNYzBZNllsc0ViUzJ1MTZUQ216ZFlHTHkySEpM?= =?utf-8?B?YkdZTXE4T0VVVkFlKzErL2tjYUV3U0hWdEEyZWJRSW52bVRCbWczTzBjVExL?= =?utf-8?B?dlBhZmg5TTlDalR6bXZHNlZxZ1p1cW1zMW1vQmJjOUd0Y0drTHJIZWJLR1hr?= =?utf-8?B?WCtKVmtXclRlaHlhZzJ0KzVHT05xMWZvTkR5d0NtRjgxUktLbnlwSFkzZzdo?= =?utf-8?B?Vk5qZWQ1VDBvWUc4bG1ad3JrUC9TS0VRck9kdGRpMmhwWXpITW5tWVNNSlUv?= =?utf-8?B?S3VTUkZ6eXFwQTVLTjZNSFRScTR5azlvUVJYWmVicldZNTBEWWI2K1BtUTF4?= =?utf-8?B?cVpuKzI4MXcxRnVFWFlYUTl5TnB0b0JjV0NndzNWYlJUK09qK25KKy9vemg1?= =?utf-8?B?MXluV0JMaHRvTEtWb1NLLzlDa1c1YWMxaW05dE51UlJRNURlbVdzUHhxUTFp?= =?utf-8?B?VGk4L3BXR05yRGxta3NScGxjUWd6MGR5Y3JVQ1FmRHhPQzZGT3locVVsMmFL?= =?utf-8?B?MHcvMnlaQkJJSTBDd1F2ZDlpaHNUZFphYWRtNDI2anh5L1NGNkJERUdONU1R?= =?utf-8?B?a25sRE1aVXg5SWhTU1pQOU96N1hhOWIyY0pWQi9na2wwRHk3cDdvWEN1amth?= =?utf-8?B?QW12TUEyR2ZRQm1TQzFDLzM0M0NJQlo4aTRTNWpOdGxxZ1cvVEJUVHpwOUlj?= =?utf-8?B?LzlPUW9GMEhHbFJwM1IxanFEUzc3S3VwSkY2Uy9nMXBsb2dERHFMK21FSWsx?= =?utf-8?B?UkVQNjdBelZieWxZRENjUWUzazZWR1VJREJKU09EY2krbGV1SWtzeXJjdkZr?= =?utf-8?B?c3Y4UlY2aEVTTUt3b1lSMTN2UVh1eEV2cEI5QkNuSnp4Z05HL3JaaTlWRlJu?= =?utf-8?B?MnEwaWl5SFFmWU1mVjhncXJjVHhYUUNMWFl5d2VkVWh3QW9QYktteURoc1Jn?= =?utf-8?B?UktieUtGNktoZjQ1NUcyMzZJb0IrS1I0d01HYkl5S3ljSDJCWXFQMG5YQ3RB?= =?utf-8?B?dnZFb3ZienJFWUN2T3JURTNiSXhEZkp1aDl2TDd1ci9sZ05TQ1c2Mk5qS0Nn?= =?utf-8?B?bnE4dG55ZWRxM1FsZjZrcW9XYXZKVVUrSXNGbkRxejdnTXJoc3NoQ1ZiWnpG?= =?utf-8?B?ODZJQVFiSWJudFBLUDNNZU1weGNUeTZENGJFaEZBenQ2TjZUOXIvZ1BaU0JR?= =?utf-8?Q?a6He8Zbknq7zraRsQ1lJat3TsceLIcDuT0oWA?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 39a29dd4-6ad5-498d-b0d3-08da401b0e96 X-MS-Exchange-CrossTenant-AuthSource: MN2PR10MB3213.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2022 19:56:58.2053 (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: MAC11zPtu/tomhxnWPbVeqq8krI5tLujjca0yG8Ob8GbYKy8JCJrmaA2oCb95v43Q+iyC++tbxLm+DtWoOuqgA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR10MB2914 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486, 18.0.874 definitions=2022-05-27_05:2022-05-27, 2022-05-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxscore=0 bulkscore=0 suspectscore=0 mlxlogscore=999 adultscore=0 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000 definitions=main-2205270096 X-Proofpoint-ORIG-GUID: 6G5CetU5Z6IpyFORRHuasrt61sfMBYm7 X-Proofpoint-GUID: 6G5CetU5Z6IpyFORRHuasrt61sfMBYm7 X-Spam-Status: No, score=-6.2 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: Fri, 27 May 2022 19:57:11 -0000 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: 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 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 > >> >>> >>>> >>>> >>>> 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 >>>> >>>>