From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by sourceware.org (Postfix) with ESMTPS id 3B2BC384F01E for ; Fri, 6 May 2022 21:18:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3B2BC384F01E Received: from pps.filterd (m0246617.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 246IwrQ4018676; Fri, 6 May 2022 21:18:24 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 3frwntf9ny-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 06 May 2022 21:18:23 +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 246LBDKj010237; Fri, 6 May 2022 21:18:22 GMT Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2176.outbound.protection.outlook.com [104.47.58.176]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com with ESMTP id 3frujcd088-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 06 May 2022 21:18:22 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iNzDOnVxl8vh1Yyd1+8l88Br1qapSHLDwbrmPnPyMda8JQBWzzBvsNeqTY93jeyxdIiHb9TYTnZfuG8ISzwAjuAbfBI9FvNxB30zAmAv6fFaSqZ75/nW2wVnov5xpT54QuDBTf1YhkIykM389fqHgc2rPNeq+szekEEdRr5XkuraAPw64eyhoWXKQSSTzSa5UEV8tB0TI0HmnTI/Q7iZK17hZzwoKdO/gGPEVVv281LIqx6H2BRGso2+76UV0ywi/H8ysXhar728s5HCeWJPFBLerXssTBLzSPW0H8KOb61yZBEFc+JseEyGECL/LDRkEsbkxr36mjFlcmGGS+z7Ug== 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=NUk+US3XJ6hzrUFOOW4x43fEn1voKZMlYgm/Y93BFck=; b=B4pqJe/buVWMu1vB3aosEfBuSojPINH4j3/z9p9Bo+kHWm/iqOZRCzduJQMrVyUNRrcfmmE1+D4gYYyogq+Rmw/G+JmUbvho1PMJdZX9fg3xgOhP5JEVdYAaDUJwy/WNWjLmhHDwKD8OngNAP4/BpvqNci5fGk4PVP89g8E7CAryTDt8cEfiZbtoIq10X1rTagiCd9lH4AJBbWRN3v1Ao0BgCH6ZBhFXFXky3gyXRORCQzkVkv0sDA2zBOAsTk/9KKHYHJk7MnWvCKIvT9B570F0wOGzYqPlZOlnVOB7YJDKWblGZTZb/I38p7t6gZpl4/Th4prr4m39TeQwlwUdqQ== 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 BN6PR10MB1681.namprd10.prod.outlook.com (2603:10b6:405:7::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5206.24; Fri, 6 May 2022 21:18:21 +0000 Received: from MN2PR10MB3213.namprd10.prod.outlook.com ([fe80::483:8783:8421:5be5]) by MN2PR10MB3213.namprd10.prod.outlook.com ([fe80::483:8783:8421:5be5%7]) with mapi id 15.20.5206.028; Fri, 6 May 2022 21:18:20 +0000 Message-ID: Date: Fri, 6 May 2022 14:18:17 -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: gcc-patches@gcc.gnu.org, Joseph Myers References: <20220401194216.16469-1-david.faust@oracle.com> <7419ae42-55c8-87d6-2a19-74cebff51fb4@oracle.com> From: David Faust In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DS7PR07CA0007.namprd07.prod.outlook.com (2603:10b6:5:3af::25) 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: 23f7772c-27b4-4ee2-7715-08da2fa5f24d X-MS-TrafficTypeDiagnostic: BN6PR10MB1681: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: hkLAM84kSYZgFeT3LWK6HtntQVIj+T+rMCSIfe4R8aP5kstkFxW0OjZC0OuGyYKe0sRe+AV7GwBOjj7WrOMysJrX8QoiXKFYIDROBavK/lMogzBl2toKTB71IiifjfoUcOgaZw3yJV3Twv0BIgVjN5wxZ7wdwc5I7pXe7/Vfm/vJDG1Q0rGiufBRyS0UrNbBwYAEwa/HZBvHCdLo978V643+HGPeSo28vQ7mWttXCJzyO7fRRQHA8c7KS6JJr/2IvspvfC+5M4ehowldj9gIVNiZTvOI6yb0xSKhJbKO0ILEiP6BVGufYsF1hawNVfwPbdFp+RRZXp+I4ryffWv44hOYm+FtxA+ezuscf1CxUKg+3OFYAyQF1LJcul1QYzz64NaO0D2tks5i3jnrLso+xa/m984SbC+8D7uU2405Ahm/51mYah+bYLNRTTe0N2kAXnoGF+FEWOKKdhOGEyXk/Mye6kscTOTlhYjvANBSGCgCheE1m/HHe7lzYze8fRmTuaLku0HMKZ2FL2Q+XeuE3mhy8I4oY8nK9gH1mZOHp82E0jrVA5pGOuvHiTvDiCAjiHxX8tJCPIDvXdPy0ZVlMVj5NIEGK6Y2Z+BmcwoKzrn+YWa+Hcct5qnOUiFPlKcWGQqmjLxwuSevLO7Xsf2qp4CnHL3elf+jcx1TXIETYAhFPm7coAY6eOOo9qEqsnzS4uaRfaqNsvw5IyuJ0hAy1PaTEcgMKUM0z8adVas1hwk= 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)(6916009)(4326008)(8676002)(8936002)(186003)(5660300002)(2616005)(66946007)(66556008)(31686004)(66476007)(83380400001)(36756003)(44832011)(6506007)(6666004)(508600001)(53546011)(30864003)(6512007)(2906002)(316002)(86362001)(38100700002)(6486002)(31696002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cVFJMHU1amM3ZVNvZjQ4QUc5cHpyUkhueVFEVWNJRURDWkUwOU9xVkVXYXBJ?= =?utf-8?B?THpIdTd3NE1HM1ZoL05GYnp2LzJHQlRBOFl1bmV4Y3BibG1UTDczcWNnR3I1?= =?utf-8?B?eTJoRXpSQktqbHNqcE1ocjFZZldXZVA2cGJuZEsvUmk3aTQ2T2dIOFZBL3Fo?= =?utf-8?B?ZWdmeGUvSEZqcXUyNndwZjFTMnN0Rm5pOTRCdGJJTlk3RWtUMnM4MU03eVFa?= =?utf-8?B?Rmg1aUZadnZDenNQTlpiV1BzcW90bjR3bmdCQTh2cFlPM0tBRjdUQTRUV2Nr?= =?utf-8?B?QTBOeGg4dXRUbjZreVBkRlkydWMxS1EwS2lLSVQwWlRTT0R2emdVRU9kNElP?= =?utf-8?B?Sk5IR1lvbTl2VVJ5ZG5DdmdTUHNPQ0MwamV2QVgrSTlFQkJjaXFieGcrQkZh?= =?utf-8?B?UkxicCtxbjhHSHBhTklWYXBvV0JIU21QcFJxQzc5UFVXYnZ2WnRxN0tNTmNv?= =?utf-8?B?VDNlUTdVS21EYk94ZUJISVUwbDdBem0vdUFaYU50bkVUMTUzWEZ2UkdXWVc1?= =?utf-8?B?d0gzTDZ3SE9WTElvZG94eThyN2VyK0lKcG16eEJTSW10eUpRNkJaSGRRWHNI?= =?utf-8?B?TFJQRUpMQ3ZXQkQvcVFoYU9DRnJ0ZmpUOFZHQjJsZTFsN2JSSU12VWQyZGQz?= =?utf-8?B?dkE0TnVqWCtvdHMrRmJtNEtVY0hGNTJzU3U2ZkpGdGZGZkJKdXJrWi9zQ01H?= =?utf-8?B?a21kVkdQWENpZm9DTUduSXdNV0sxeEQ5Y0RsZlNWRW54REhFT0ZSaStDZmdZ?= =?utf-8?B?RnFvSzlxK0FXVFRIMSsxQnFoRjYvbmpTMjFjd0tJNHUvSmFKdmlBOGhyWElR?= =?utf-8?B?QkIrNXJxN3o1aWtwNTZBSHg1WVFyRGh6dDJ5bEQxeDhlYU1ycGRIN0x3V1lm?= =?utf-8?B?ZHpMNDBUVkRBV0dEdzA3QXNxVVZ3ZWtQbzI0NFhtOW4rTVUvSFdObXVyZUp1?= =?utf-8?B?d1JkR3NpY0VMREE1U01NZFR5RXByUDd3SGsrdm9BekZLL1hBazhpSzIyS0pF?= =?utf-8?B?Q2JVb0dLNjBpUXJtNnM0U0w2bEdwa3I3bnYrY3ZTUU0zaEQ3VXdlYmowZjJH?= =?utf-8?B?Q0FsSExjWlpicVBWdzZtMXdkaWZVM1FKZGJURWpNNk9hQUZvVks4MDBZVmRl?= =?utf-8?B?SERwNWNSdU9KeVlZb3hGMzk1WEVJMnU4RjNkVzJ6ZDFuaU1VK0ZNL1kyNWlP?= =?utf-8?B?aCtzU1ZjR1oxNWh3aWhzRktqU2I1cUhaeG9EdjZnVldzc1pPRi9WK2pUdjN4?= =?utf-8?B?cUw3SjBSbDgrclFSaU9ETTRKNmVwZUpoRGErdjVOdk5ldGNxVXUxUUdoNWJY?= =?utf-8?B?Slk1WmNUQ2Nxemxyb0NZRjZZRDhFMW9naTArVTBrdTM5dFpCQmN0WDBDZzFl?= =?utf-8?B?OTFxQ29VaGNpT3Zkd0h5M0R0N1RtWlhtL1VDQjk0QUc1cXhEWkJZbWJjenJx?= =?utf-8?B?aXprSGZCaXMvTlV0cnRBSXBtWFFMRitudGFPMGlLM3F6QmNuOVBXajJicFVk?= =?utf-8?B?NDVjb1pYMVRyekV3R2JONXQrS1FsMXg1TjNIRDZob202VHpoTEtPRG4wcWFn?= =?utf-8?B?aDJvYVBMdU5IQWVGYXJ5RW1kejd3Mm5HNDZ6MEdXY28yYUM1a1ZDejlmb3c5?= =?utf-8?B?c0thaFlMZGtIcHcyMzdtNkRqWUN0TXJDU2tDU1NNMU1IR1gySFliY2ZrcHUr?= =?utf-8?B?djJPMTI0NHlMRmd4NERuNHlJZUNhQTRVa3hZZWxhKzBZYlNxaXpSRzUrV3Ay?= =?utf-8?B?K3BwM1F4eXFmUFEyR2NveitMV1djTGxHaS9RcGpCWXlZMC9mc1dqWG1QWjg4?= =?utf-8?B?REprTGl3bDBSWXMzYW5YNDF6ZTZuclMzMWlUVzhuUkJ3bUd4ZXFZRDgrMU5p?= =?utf-8?B?U3VpSVFPcHBaUVZLUDBrRHJ0cG15eDduNDUwQnl0eTF6VVZ0MmtOb1krdHVT?= =?utf-8?B?UFloQnRJd2lJRm5rNjg3cTZSOENySUpXK3pHZWJsL3RJV2dMZENjVThUK0wz?= =?utf-8?B?NkFsM1AxRWRLYTJyRkRjYlhIKzZUOHQyb2JXNEVTa1oxMEFuSHRUcEE5eGRn?= =?utf-8?B?Qnp2ZmQ1Y2d4U2plTUFxTGNuRFVIb2lKdG1CS2hCWTh4UzQ1eXpidGcwYm5q?= =?utf-8?B?SkVLUmtDSVlUL1FOdjZFL0FXajlTT2kzdWRXWHAwUU5DbjR0TEJ1Vk9Tc3lN?= =?utf-8?B?WVVpK04zdEw4TE9TUUlpckVWOS80Y2FKc2dzS2Z3YjRjelFrcURSRVBaYlpF?= =?utf-8?B?NTlNUFZyNzQyNVZTVkpEYi9oSk9vcy9jZ214eUNPV1Izbm1SWlR2ZTB1Mkdi?= =?utf-8?B?VDJ6QkNPVnFWRmNMNnRVK1lrOWFYMUZWd21RbDFmQ1NFZkNZRlBYQ1BsQlJP?= =?utf-8?Q?Vo2RZkPgIdkw7jsPAlOxvc7V8ceLMPfkPDDjg?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 23f7772c-27b4-4ee2-7715-08da2fa5f24d X-MS-Exchange-CrossTenant-AuthSource: MN2PR10MB3213.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2022 21:18:20.9024 (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: 9ULwc3Vdtpjb6SdrLVZy5s6EHxFN4b8La4GJGIdVIxdTcZmD+cpwi/ULGf5lAFenuswUKdbB549/hxbRdR0EIw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR10MB1681 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486, 18.0.858 definitions=2022-05-06_07:2022-05-05, 2022-05-06 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxscore=0 adultscore=0 bulkscore=0 suspectscore=0 mlxlogscore=999 malwarescore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205060109 X-Proofpoint-ORIG-GUID: 4AXsnbST41o69naFNr65osqBoMbi_4K0 X-Proofpoint-GUID: 4AXsnbST41o69naFNr65osqBoMbi_4K0 X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, 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: Fri, 06 May 2022 21:18:32 -0000 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? > >> >> 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 >> >>