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 310D3385801E for ; Thu, 5 May 2022 23:00:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 310D3385801E Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 245JdInT000766; Thu, 5 May 2022 16:00:53 -0700 Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2169.outbound.protection.outlook.com [104.47.57.169]) by mx0a-00082601.pphosted.com (PPS) with ESMTPS id 3fvkcnhurd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 May 2022 16:00:53 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q328cyY6bXrpGUNDXFsjpDoUjL5hqUDoR6zp4KXq50CxckTnQSZB6+cXlRZ4ThCMADHt/nics2YIGVApS6MiO/OAvTCWHrXOMz0i3pe5MfvGpHxbNpJovJmMwG6CwOJpOuzdtSHvBUAd1Ea6301xK9T/yo6MYSNUHmoxfY/y/mUBGBPgFINUn37PZF+UVScUIzSsVw1KczvWJvj6THuMFB17hbK3sr7Gx3RYHWdqfLdQAt27m3WD+J2wdHKaSh2LqgxyTA2CTOvIUxE0oVf46zxQswak7XGCRx/A2UvfbsYynfvUihJ+r5/zQaXKja1IiQOdc7ZjPOyFUPd1pYpIUA== 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=4MKj54d8jAbTZgiFOlXtTuCjITkTkh0sLgL39P6WAtY=; b=SEZM+BbqAXDCOgyNctcG8buWbdrf4t7Kr9vEo2iZmL10XwOlIeHCaf2kOtSajL4F3+gDwYbC91NFWpwrCY6yqUwW2JI6hGw+MQO9B4YZ9swqHPrQ7ZLXkFUCwGaQllwVXwOIf5Tl92FHQ3KH4UemMcCUr418t8Sm/Axz/eIieuK3jduklo3o4lafAKln7VcXO14472GT6+++V13V9MRAti6v9Ei6XzN1lOYrYXOMJrhZCG4AIr6RCSN6hFXsIQNn1ShyBELjkIAV4soPcgjTeXpx6YwN451jtI2mOPd2SYlPG6UAvRTvqdOCav0awDda378VzZVnzGKLyVoGVFFvww== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=fb.com; dmarc=pass action=none header.from=fb.com; dkim=pass header.d=fb.com; arc=none Received: from SN6PR1501MB2064.namprd15.prod.outlook.com (2603:10b6:805:d::27) by SA1PR15MB4529.namprd15.prod.outlook.com (2603:10b6:806:198::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5206.27; Thu, 5 May 2022 23:00:51 +0000 Received: from SN6PR1501MB2064.namprd15.prod.outlook.com ([fe80::5811:4996:bbfd:3c53]) by SN6PR1501MB2064.namprd15.prod.outlook.com ([fe80::5811:4996:bbfd:3c53%7]) with mapi id 15.20.5206.024; Thu, 5 May 2022 23:00:51 +0000 Message-ID: Date: Thu, 5 May 2022 16:00:49 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [ping2][PATCH 0/8][RFC] Support BTF decl_tag and type_tag annotations Content-Language: en-US To: David Faust , Joseph Myers Cc: gcc-patches@gcc.gnu.org References: <20220401194216.16469-1-david.faust@oracle.com> <7419ae42-55c8-87d6-2a19-74cebff51fb4@oracle.com> From: Yonghong Song In-Reply-To: <7419ae42-55c8-87d6-2a19-74cebff51fb4@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SJ0PR03CA0362.namprd03.prod.outlook.com (2603:10b6:a03:3a1::7) To SN6PR1501MB2064.namprd15.prod.outlook.com (2603:10b6:805:d::27) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 474b039d-d261-40c3-9981-08da2eeb19f6 X-MS-TrafficTypeDiagnostic: SA1PR15MB4529: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: ZekBOFvbJ1sL3zVTj+xDeWCu/meXu1pRT1XTet4NG0SkB33lw3KJ537jh71ZKX6T7aZezVS5zxbrJxYFbv7zkmOFNly9b1kpEB3uWeMv6NFjZPDXCBIcvP9GNPSAqMtsHGavE7evtT74OV2Dg6Aw9zZocMx6znw5vp0aqWBvmvlF0nRcR9lAhmzsUQ3pQnxeva7qSUW+WIxN5bs5z1kzLEId3DYoRfQjrye90LmCOQeyzXvkuFtTskrOqTRRPYllAEphJ6BLhxa+h2Ijd86Y7nmMcZpc7RKggl0CWGTFWJHWEiklU/R2B1y0uxO+aNxHm00IUk+Vr0PKGGAA5H/xYwRL0ZztbpWrejAP1awBxdbh5uNg+JFwc1l+lKCK8QTkbC1ce33KLLx0jhxC7kkHUUdNmzhsceqJYqtY5CQqB2yEExAHSC45O8trHY2urWt4kU+t5hbHu6+akvTcQ1EdodOwUnsZW0PII6Md0Z7J62diQh0A5a4d5OKw+GUNBvra2OHOcu3BZ5LZIB1FF0iJCU/o2gG62tGpJ7D0qMK90wxCuqUTXEkpG7+lM0R2TOuqW22JYXSTizl9mk3s80Tg3gZCx3Vx0+LoccFmspQRI3OBdh0daR3QrnX2dfZ+WZ490u67/qI+13QquIISU55CX0OcNhmyGkify9H4dDcg4L1aAyOtehZLH5n2nqeg7m/UtaTkwuqDE2Zaf1a/XZ1oNghSvQ++9MooOfNsX+PckqnIvCpLLkgHLfYWN4WRBk57 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR1501MB2064.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(36756003)(8936002)(31686004)(5660300002)(508600001)(86362001)(83380400001)(31696002)(6486002)(2906002)(186003)(2616005)(8676002)(66476007)(38100700002)(66946007)(66556008)(4326008)(316002)(110136005)(6512007)(6506007)(52116002)(53546011)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aUNVcTVwRGxNNEN3OHNUVVBqZjFyZkY5bHlGZDk3YlZ2ZUNxQlNyQVhlVEIr?= =?utf-8?B?a3lyWjkrUmFhclJtdTRlMC9nREFEWW5FbXhsWUk5dW16YnlrTnQzbGY2cHR2?= =?utf-8?B?d2duNk1qMnhtWGhFTGRDakZRVG9Ma0VOMzhXUXpGV1F0STcycFVhNzgzdDRS?= =?utf-8?B?aGd5UVFoRFR6eldnZmFWV0lCVVMycDFtRXduRzhxQ2h2TEEzWklsVFU3NGR5?= =?utf-8?B?emladW5FZ1A2VjdHKzAyNE9CcVJXaXQxVVI5Q3YzeVp0UXdKaUgrYWV3VTZk?= =?utf-8?B?bFgwUkJOcVpGSTM5T2FtbkVqUHc0dkFkeFZHdGFDaDZLZSttTU9RUU9Rd25q?= =?utf-8?B?RkYrYTF3bkF1M2ovd3Z0TFlSMTEzMHRwdUlvb3FuM0pUYmlPVEo0UTk5UU8z?= =?utf-8?B?Nm9UWUFCcVpLU0xJT0lEMTZ0RlVEU08xUm1uWGluRWcwd1g0VDlPZG1aUng1?= =?utf-8?B?MXNxanlIUVJkV3cxNG5xbVNGNlozTjlLKzc1V2MzU0Mzb3JrOUovN08vNEpY?= =?utf-8?B?ZDJBN21yNlBjU1ZEY2d3YThLK0RxTTFtak9xZjd4Rmk2NVZYT05EeXhydEhH?= =?utf-8?B?L3V5YTZJRnBXa1g0ajJzTnV6anYrZFRtalRYaEltZ1RGOXZIdVBEeXdobVdC?= =?utf-8?B?cW5CZTdDN0JCZXFHVHN2TU05YjBpQzNYelpTOTdUNHFaZzhsL2lyV0N4Vmoz?= =?utf-8?B?YTNaKzZSQlZ5S0tSdXdIMUl5Vk9IYzhCWlpqZ2tlU3lMbThwMzdzVlEza0d5?= =?utf-8?B?ZGhoTlRoK1NzMWtUZE93S0tyVU8zMTlCWmFJQkF1bTQ2ellYMU8wSjlIeTM3?= =?utf-8?B?MnNQSFhMbGtGVFQzQW1nKysySE4zTXJ1elZKTWUvbXAzbzFkUzh6dUQ1WkJG?= =?utf-8?B?RnJVblU4OVQ3SkJkYmJnOXd3blhUVTVleS8zeWlubHFsTVJ4V0FHRTJzZ3BC?= =?utf-8?B?ZWx3ajlSWnJxR0UrbzdyTngyOERlM2h4QlJCeUdSSUxNMjJ2ZHhaUE4vVEIw?= =?utf-8?B?KzR6bjdGN2ZTOVlTTVRUY0QzOGk3eXZSSGRNV0lncWlIUDFpVG1KNEpzM1pu?= =?utf-8?B?Y2dxL09wSmhYWGthZk11QXRMR3B2ZUlGNnZrMFpzQ0JlQkc2RnBiQmZYRUI4?= =?utf-8?B?N3pOU2ZPanprbmNQZStIU1BmMzdVK3BBYVQ2MWE0Wk1VRlFQaThTYW03TFVI?= =?utf-8?B?MWdWZkZhU0dIWWZZTFpGTGVEaDhjL09YbitFNFVGendVelUzVytIdVBoRjdE?= =?utf-8?B?Wm1LTHFMM2NLMGhQYUdvbjFReERtcnBzMlR4Z1hpMlpYODl6bnpnSFpXbFIx?= =?utf-8?B?akI2NnJpeTlyaGhzUTFzMnNXK2x5U0pZWXRxRVN0Znp1aTlwemIycU9sR3Uy?= =?utf-8?B?ZTBkU1JyMWJPOFk4K2hhbGlvOEpZVDgwUmdqM1U5bmJLZHFNQUJxZ3VMZkZn?= =?utf-8?B?MThkRDJiOHlaM2pJOWxMSmw1Vk9PNVRYbGxqU0dwS2lIdXZ2TG9jZVlhK0NS?= =?utf-8?B?VDlHTDJZdC9DNzhXTHVwUU9TeTZxUDgxSEhuSGFRc24vUkY3R001ZlB1YVZr?= =?utf-8?B?Z29MUXBzT2VCSU0rNndRdnZNQlltbjMydEdnNEVKL0lON01QQSs2YzVhSTVw?= =?utf-8?B?VnE5YjJjNFc2RlVGV1ErUktYTHdvNjdpYkhWMFNHZExQVHdqb3hiMWhHMU1O?= =?utf-8?B?WnlkMFA0ckl0UkFocUJMazFyQXVRZUdNQ2tGdUlPWldyazQwd1lZeW9iU2Uz?= =?utf-8?B?Um16WnRxcWdVRlljMHRrTml0ZDJLR3QvSlB4SDl5STJ0THFZT1NsWElXTDA3?= =?utf-8?B?KzdCUU9keStndWx5amhUbm1aTWszWmdhZUQyV0hEYUVKS1l2MmRCenIrbGVD?= =?utf-8?B?RU5ia0MrNm5WYjY1UmRXL0pqT1RYVVlGbEhnWGVudnFVWGZqTTNHR1BKTm53?= =?utf-8?B?SU5weE9IS25ndENtZkZaWEROV1FqM2VGRXNCNW9Zb2c5Nkt3RU1SamM5RDlC?= =?utf-8?B?THFyc2Z6d2FlZFFpNFV3WEhUakVaeDlOeS95M3RFbGJYNlloald6YnVvVVpQ?= =?utf-8?B?SUJUS0E0aDdTbFd0MmdCQkR5SXphLytuZHNPdlVJNlhSNmNrd29xUDdyYzBZ?= =?utf-8?B?eWNNR2F4TzNhZHJrL2RLSXROZy9QZHgvT1JUcTZudkVkazFkUG5MNGxuRUlB?= =?utf-8?B?cWxhLzFBMFVxYjYwMG1IQWhtTDVVN0dwdTRYc0F1T2dqbk5hS3Z1MDJTMWJx?= =?utf-8?B?bDBTSlg1VUxDOEljZStEa3hEazVKNDZISXRjbklVbU1hWjFGMHJGOVIrZXJB?= =?utf-8?B?SWVEMDljdktzdWlYVTR0RDhMTG5iUDhva3dyMGRMMzhzbUtOS3lDVjVzcytH?= =?utf-8?Q?yllXjrGph2lr2tTk=3D?= X-OriginatorOrg: fb.com X-MS-Exchange-CrossTenant-Network-Message-Id: 474b039d-d261-40c3-9981-08da2eeb19f6 X-MS-Exchange-CrossTenant-AuthSource: SN6PR1501MB2064.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2022 23:00:51.5067 (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: AyYa8Ng6e80n/BhP6U9C6WNo9SEMhfHBSt8kPoUkotf3f9bMaCDMr2UY7TuA2SDb X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR15MB4529 X-Proofpoint-GUID: YNde_byIEMlFomLvQ39FJuQZhKtSWLAB X-Proofpoint-ORIG-GUID: YNde_byIEMlFomLvQ39FJuQZhKtSWLAB X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.858,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-05-05_10,2022-05-05_01,2022-02-23_01 X-Spam-Status: No, score=-3.7 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2022 23:00:57 -0000 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) > > This example comes from my testing against clang to check that the BTF > generated by both toolchains is compatible. In this case we get > different results when using the GNU attribute syntax. > > > To avoid confusion, here is the full example (from the cover letter). > The difference in the results is clear in the DWARF. > >> Consider the following example: >> >>   #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; >> >>  >     type >         type > 0x7ffff74495e8 int> >>             asm_written unsigned DI >>             size >>             unit-size >>             align:64 warn_if_not_align:0 symtab:0 alias-set -1 >> canonical-type 0x7ffff7450888 >>             attributes >                 purpose >>                 value >                     value > 0x7ffff7509738> >>                         readonly constant static "type-tag-3\000">> >>                 chain > >>                     value >                         value > >>                             readonly constant static "type-tag-2\000">>>> >>             pointer_to_this > >>         asm_written unsigned DI size >> unit-size >>         align:64 warn_if_not_align:0 symtab:0 alias-set -1 >> canonical-type 0x7ffff7509930 >>         attributes > 0x7ffff753a1e0 btf_type_tag> >>             value >                 value > 0x7ffff7509738> >>                     readonly constant static "type-tag-1\000">>>> >>     public static unsigned DI defer-output >> /home/dfaust/playpen/btf/annotate.c:29:42 size > 0x7ffff743c450 64> unit-size >>     align:64 warn_if_not_align:0> > >> >> The current implementation produces the following DWARF: >> >>  <1><1e>: Abbrev Number: 4 (DW_TAG_variable) >>     <1f>   DW_AT_name        : g >>     <21>   DW_AT_decl_file   : 1 >>     <22>   DW_AT_decl_line   : 6 >>     <23>   DW_AT_decl_column : 42 >>     <24>   DW_AT_type        : <0x32> >>     <28>   DW_AT_external    : 1 >>     <28>   DW_AT_location    : 9 byte block: 3 0 0 0 0 0 0 0 0 >> (DW_OP_addr: 0) >>  <1><32>: Abbrev Number: 2 (DW_TAG_pointer_type) >>     <33>   DW_AT_byte_size   : 8 >>     <33>   DW_AT_type        : <0x45> >>     <37>   DW_AT_sibling     : <0x45> >>  <2><3b>: Abbrev Number: 1 (User TAG value: 0x6000) >>     <3c>   DW_AT_name        : (indirect string, offset: 0x18): >> btf_type_tag >>     <40>   DW_AT_const_value : (indirect string, offset: 0xc7): >> type-tag-1 >>  <2><44>: Abbrev Number: 0 >>  <1><45>: Abbrev Number: 2 (DW_TAG_pointer_type) >>     <46>   DW_AT_byte_size   : 8 >>     <46>   DW_AT_type        : <0x61> >>     <4a>   DW_AT_sibling     : <0x61> >>  <2><4e>: Abbrev Number: 1 (User TAG value: 0x6000) >>     <4f>   DW_AT_name        : (indirect string, offset: 0x18): >> btf_type_tag >>     <53>   DW_AT_const_value : (indirect string, offset: 0xd): type-tag-3 >>  <2><57>: Abbrev Number: 1 (User TAG value: 0x6000) >>     <58>   DW_AT_name        : (indirect string, offset: 0x18): >> btf_type_tag >>     <5c>   DW_AT_const_value : (indirect string, offset: 0xd2): >> type-tag-2 >>  <2><60>: Abbrev Number: 0 >>  <1><61>: Abbrev Number: 5 (DW_TAG_base_type) >>     <62>   DW_AT_byte_size   : 4 >>     <63>   DW_AT_encoding    : 5    (signed) >>     <64>   DW_AT_name        : int >>  <1><68>: Abbrev Number: 0 >> >> This does not agree with the DWARF produced by LLVM/clang for the same >> case: >> (clang 15.0.0 git 142501117a78080d2615074d3986fa42aa6a0734) >> >> <1><1e>: Abbrev Number: 2 (DW_TAG_variable) >>     <1f>   DW_AT_name        : (indexed string: 0x3): g >>     <20>   DW_AT_type        : <0x29> >>     <24>   DW_AT_external    : 1 >>     <24>   DW_AT_decl_file   : 0 >>     <25>   DW_AT_decl_line   : 6 >>     <26>   DW_AT_location    : 2 byte block: a1 0     ((Unknown >> location op 0xa1)) >>  <1><29>: Abbrev Number: 3 (DW_TAG_pointer_type) >>     <2a>   DW_AT_type        : <0x35> >>  <2><2e>: Abbrev Number: 4 (User TAG value: 0x6000) >>     <2f>   DW_AT_name        : (indexed string: 0x5): btf_type_tag >>     <30>   DW_AT_const_value : (indexed string: 0x7): type-tag-2 >>  <2><31>: Abbrev Number: 4 (User TAG value: 0x6000) >>     <32>   DW_AT_name        : (indexed string: 0x5): btf_type_tag >>     <33>   DW_AT_const_value : (indexed string: 0x8): type-tag-3 >>  <2><34>: Abbrev Number: 0 >>  <1><35>: Abbrev Number: 3 (DW_TAG_pointer_type) >>     <36>   DW_AT_type        : <0x3e> >>  <2><3a>: Abbrev Number: 4 (User TAG value: 0x6000) >>     <3b>   DW_AT_name        : (indexed string: 0x5): btf_type_tag >>     <3c>   DW_AT_const_value : (indexed string: 0x6): type-tag-1 >>  <2><3d>: Abbrev Number: 0 >>  <1><3e>: Abbrev Number: 5 (DW_TAG_base_type) >>     <3f>   DW_AT_name        : (indexed string: 0x4): int >>     <40>   DW_AT_encoding    : 5    (signed) >>     <41>   DW_AT_byte_size   : 4 >>  <1><42>: Abbrev Number: 0 >> >> >> Because GCC produces BTF from the internal DWARF DIE tree, the BTF >> also differs. >> This can be seen most obviously in the BTF type reference chains: >> >>   GCC >>     VAR (g) -> ptr -> tag1 -> ptr -> tag3 -> tag2 -> int >> >>   LLVM >>     VAR (g) -> ptr -> tag3 -> tag2 -> ptr -> tag1 -> int > >