From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) by sourceware.org (Postfix) with ESMTPS id 38A3C3858288 for ; Wed, 15 Jun 2022 22:56:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 38A3C3858288 Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.17.1.5/8.17.1.5) with ESMTP id 25FLplh2003592; Wed, 15 Jun 2022 15:56:30 -0700 Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2169.outbound.protection.outlook.com [104.47.59.169]) by m0089730.ppops.net (PPS) with ESMTPS id 3gpr0edsrr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Jun 2022 15:56:30 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N9ilHVXq0mnSv7BsMU2PRP/Ep0JPtFcqZ2qQXV4IBFn4bu2SBP3vs1J4YKjVvJVr8beBg/KcGto2gZ9AhiNf0TDrFXd2Nndk0MFrisMFDHCguvjMBFmELf/65qmrvk6zRBc+RZRLyyvyI4vkawqG/wezzGijODTutqvRjWYkcuO3gyDBbgQrBKcW/fM7ud0wRnMT04LM4HXzNbD6m2WoOznea9N+Hsv7cnxGsiD5lZfjMV2bIsbeX/SPUHsbdccRGl4e8IRqFKRIL72f8JXGq8TXLMtHUS0zLin4hNeJbB0Ow3tV7eXoDuBG2xUvYLp9sERSA9z0o9VRlQYoREEIyw== 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=XYwu3GBOkVNXQ5UYY8ND4WY8gPhATwvVvRwQ/J9Bb5s=; b=AhlE8/+z2/BS1xbS2B+xmOs0FGKcMqnPD1nU2uen067moxH2KHPuLcckXnKSW/JDnMSk7/QIz2SK87WkvYmLk2bfwkn1ucC27w39HnJ2pyiE3hWh+Vv0HsVrMS9lR6nxu52YlWj7SLnxHX8+4O3hGmMnD9t7o1PQIvhYGrj6I7yYPwTn/U5aBLOizRZrqx9/Ha9LmYPLLBVPvg2PH3V4uhqJQbRY2YJHiuercJmyEk60i08qycvu37bNvNyjr15cCmz3TZ2XHyuTOM3V1tUA9XzURwVquKhcSk3B9Wq2w3ktGZ439A4LTdX3sFV+Ju6Rb1WSwo7vUUKLyQAeG0fpcQ== 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 BY5PR15MB4273.namprd15.prod.outlook.com (2603:10b6:a03:1fe::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.14; Wed, 15 Jun 2022 22:56:28 +0000 Received: from SN6PR1501MB2064.namprd15.prod.outlook.com ([fe80::482a:2ab1:26f8:3268]) by SN6PR1501MB2064.namprd15.prod.outlook.com ([fe80::482a:2ab1:26f8:3268%5]) with mapi id 15.20.5353.014; Wed, 15 Jun 2022 22:56:28 +0000 Message-ID: <52dcfdb6-f1b9-1986-5d10-8d6ac8c6d256@fb.com> Date: Wed, 15 Jun 2022 15:56:18 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH 0/9] Add debug_annotate attributes Content-Language: en-US To: David Faust Cc: jose.marchesi@oracle.com, gcc-patches@gcc.gnu.org References: <20220607214342.19463-1-david.faust@oracle.com> <2ab1d9a1-0077-a1e7-f212-556fcf8c8883@fb.com> <9bd41e20-5c39-0d35-bd6e-c10c65280da7@oracle.com> From: Yonghong Song In-Reply-To: <9bd41e20-5c39-0d35-bd6e-c10c65280da7@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-ClientProxiedBy: CP4P284CA0017.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:128::19) To SN6PR1501MB2064.namprd15.prod.outlook.com (2603:10b6:805:d::27) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1b509bff-1210-4080-9200-08da4f22478d X-MS-TrafficTypeDiagnostic: BY5PR15MB4273: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: ma6k/WTsmsWOynHW4MM5Ul3lEZrF1WJjVqsk2WUdMRJ+4ekyK/fwPAnbBQ63BqJTuNcVQwBMYM8RB2YXcfUVQro2RSuziEajp7dQG8P/I5MarJ/aMePxzZWZWP8tS1fpvX+40z3QFmYvHGLJugu2NCifBTHS2rx89IGj8lnBUNQONzV2FnJheKrgNk8vj5/ymQnqyKc+qAatklo5gE75/5J+dRlaphEImXZtK+VcvXaVVsp+iXsou1CavgObLS0pzMT7QksmTb57V6AwwquxLMXIDS7U4sUhvFpFWf7hV9I+GYFigttxXXE04K6L6NO3TCj7shRG2frDxy0ze04W76UGCPHMjnBJgBcMk9rBsUHtlvchpFC9+HuIbx1LUCf6TCvUyD52fpHWrvrthhuUXri3ny8YfJRcz/S+oiy9obcGLg/cmqC0SiQktDB7z+WvTljUwQ/e7Y4sXbApeJj9llKyELFDXkFxnHE/+vIUYwktY9oLMIBLQi89HWyL3xCYZncqxzBXpPFuilVuTge5e69sn1/5sLeI6jgz25+dE3b/B3q/Wm0rFjSNrzB6t+l8253sS5jZ1Xi42J6Ny4U36QG/D6dGBUJB61231FMank5kVWaoNE2QimK+9bGuXKbt4xjSbi0p41+CiMKksU3lhP5qW0LMdvX33Xxx9aQNisI8C5iBJgYWqkTjcIkMPTxFeU8WZCF+jUiTGJjdsPeXYznnRLu8homZ3pPwRMIbkM9W59U6lBkuFI+guZkx11lDRI4X+PscwxRL4BT5MXF8n6add+WAYzYq8elpv3nj24SyuUtzTFpPShnUSebzKDPfA4CM+EfUDSRXLqu7k65xst8rmfpFv+r28tGNwt9Yn/U= 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:(13230016)(4636009)(366004)(4326008)(2906002)(66556008)(8676002)(31696002)(86362001)(66946007)(66476007)(38100700002)(8936002)(5660300002)(6512007)(53546011)(186003)(508600001)(2616005)(966005)(6486002)(6666004)(6506007)(31686004)(316002)(83380400001)(6916009)(36756003)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UWkwb2wzQnZ6RW1JT1RLc1hLRGxRKzMyVEV6L1ZkRTA4MnN1dysxU0dlbWgr?= =?utf-8?B?UnRtUHB4Q1dPeXoxU0dzMWN1ek00TVpQdHlJcm0yTWdqaXFDVGhqWG41eGFp?= =?utf-8?B?bTFjaERSNmVEdUJWVVBGQ0pTbVI5aW1MMk4wUXpzK0VhTUdnK041eERhWjFG?= =?utf-8?B?SUpQbmg5Nmcvd0xjY2RlZC9ZSEt0WkJzSUVPWDdXcW9hNm9ZYkJsVWNrR0cr?= =?utf-8?B?Y0dxRWJIRmhHRUc1L1dqRVQvQS8vSEw2Z0xNa0pLVWU3TDdBSCtiKzNiT0JH?= =?utf-8?B?aHQzdUlQUm1BWjRxOUtlR01UVmJjVE1adGV0WDg1MG83V1UxM1h4ZUJIRTFZ?= =?utf-8?B?S2JXSVhCdExmUyt0YXBYa2JnUXZGeElhMUFUOGl5bHI2Smh0dGVydUFZUHR6?= =?utf-8?B?alBXekNvZnRmb296M3NLTnBMbDQ5SDJsYlZXNTJIMExZWnY2ZzR6YityQ1Vk?= =?utf-8?B?QlpXcEN0M1VNN3RHcmtKaVh0Q2d1NTRqWERFaWRFcSt6V2FLYVhSL20raDNt?= =?utf-8?B?dmdTNTU0VVJrV01uVlhFK3EwT0VVanlWSXVXeFBDRFJiblc4YzVoODIyc1Yr?= =?utf-8?B?NGYwUXJYclZXYk9LNHR5TVBxajU0V0tPTTRoN01Cb3BVVXRtNXJXS2NkLzEz?= =?utf-8?B?cjhoM1dLN0JFTUE2RmFmVjk4eFNqbjk0RGVqbGcrNVh4NUppK1lwd3BzL3Bt?= =?utf-8?B?VDluNzhkNEdlUncyRW0wZHJkOUF5ZHJwMzE1R1NGemdkdVhVM0ROS1M1ZG9h?= =?utf-8?B?czgyWlllS3RXR1JuRC8zZE1ndWE1eFVQRzI2dkduQXFsUUF1UzMxRFNjRFdO?= =?utf-8?B?QzVFLzVJd01mUGQveVN6bWdFeUQzeTRhVUdRWWNuaFM1MEdubThKd2MxN1hU?= =?utf-8?B?MVBTdzE1UUJPVDh2UnlDSkFIcFFGSzV3dUloMW53U1JpdDN1TmVPNm40S2dG?= =?utf-8?B?MExQSEEwWXBiL3ZEdVo4MWZMckpkMk04ak55bTZXVE9CdzZ6dEVWbUowQkpN?= =?utf-8?B?OHQ5NTQ1eDJMT2pWV0kyektqREtlbkEvRzdNd3EyenlaZHQ3VFZ2YTF4VW5M?= =?utf-8?B?a3BrZDlndXlXVWVadWR4Y3F0L2FTZTNWaTFBczNxQmJWNzcrWG93Vy9xcDBC?= =?utf-8?B?TFB6MjhUOXFTRXFnRHhKL3FDVHJYMUhyV1pjZzA5ejRZN2IrVUdyMHRWNytt?= =?utf-8?B?S091b21yL1lQTHFCRDZQNncyRUJkMTlJbHNJa09lV254dktoRE9zbkVNUkhF?= =?utf-8?B?enUrcXV0a1NMQzI1R29FeTlFbWFyN2o5TWxPdUpqZW9vT3BndyswYXZNOHhy?= =?utf-8?B?Z1NZK1Zrblc0U3lLK0d6N3FFM1lzdGNlcVdidXJYTit2Zm1hS3dHeEFZOEg2?= =?utf-8?B?Z2RFY05nUkgyMS8wVWI5MGE0dUVteHFQNzA1amRVOGpjWG53c2tBeURWcTNa?= =?utf-8?B?R3g3Y3V2UzgvWVBVNW0rK1Fkc0Fja2hTWG1EQkpCbk0wY25BMEpOTElDQlZr?= =?utf-8?B?eUlKMmlCd2NmK2JTTWozb2U1cUt6TVl2ZWlKOEdZMVVTOUw1eFRzVW9sVk1p?= =?utf-8?B?ZXNMNHJrL1FsaXZGTXhkRzVOVGNLZmRURDd3SEdPMnRITE5BTFIxaGErQ29N?= =?utf-8?B?bCtJWUFtWUptcTZoeWFRU21HTGFSTENhSzJ2YjNvOUlUMmNjRFRGZE5heDEx?= =?utf-8?B?NjlpTVRGWE50UWM0VllhYkVUS0ZYNlpYdzJRRnRoVnY4S0dEMkNjOXI0dHJx?= =?utf-8?B?WGthVTE0dnZrUmdldmgwbUZUY0l5am1mNGxZMHJIdDFLVTBDZHMyTk1YNjBT?= =?utf-8?B?bmQranFIM1d6MTVMRVhESVYrY05QUnJwODV1cTdKemIvQitURklyVm5iUFVm?= =?utf-8?B?RG5yOWRKMnBXaS9kWWkvbWsyblhmSzdlN2c0d1N5b0M2ZzJLQVR3Z1RtL0tF?= =?utf-8?B?aUFwNnV0cUFYc0FsWUI3d2tKdFZvVjRQZ1dBWXlGamFtZCtHUW9UeVNSWVBU?= =?utf-8?B?L0dpQktCTHJqYU9EOHpGY0UvS2l5b0pZSy9Fb2h4T3FNMkpGSXpTZHFjWkg4?= =?utf-8?B?SVdVZXQ0L1lUc1dFa2p0Uk1nb05VZWtIditJaWU3azNSSW5RR2FOUTZDejdR?= =?utf-8?B?Mi9nMXlJNTBSUWlXRjJuUC90VXZxRFRMcXdwQnErUFVkVEdvUU9wSFpyNUcz?= =?utf-8?B?WGpFbkV2QjVyZkxrVDk4S2MxcDYwaW5LTU1jOHk4VHpvdTZGSzBFaUtUb1Iz?= =?utf-8?B?NEhjUHhNbzZjeE1SNE83MzBBL1RVOERaUWZGWis0dzVpOURZcTZxS0N0bTZq?= =?utf-8?B?cUpBT2hNSUFtMG5RMVBKWjFuZ09xV0d2elh5TWRBc0hmSXgyZ0ExVHY0N2NT?= =?utf-8?Q?BTT5NzyiE6k9S9us=3D?= X-OriginatorOrg: fb.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1b509bff-1210-4080-9200-08da4f22478d X-MS-Exchange-CrossTenant-AuthSource: SN6PR1501MB2064.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jun 2022 22:56:28.1788 (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: ex/Aa57Cy2cibMtGC+chevpalVWXqItP6Q714TFIR0137w24RAyabvzN21DVDWy7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR15MB4273 X-Proofpoint-ORIG-GUID: hrg5KRGOBKMkmOEe7vcvJjL5CdzjOr6S X-Proofpoint-GUID: hrg5KRGOBKMkmOEe7vcvJjL5CdzjOr6S Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.874,Hydra:6.0.517,FMLib:17.11.64.514 definitions=2022-06-15_16,2022-06-15_01,2022-02-23_01 X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2022 22:56:33 -0000 On 6/15/22 1:57 PM, David Faust wrote: > > > On 6/14/22 22:53, Yonghong Song wrote: >> >> >> On 6/7/22 2:43 PM, David Faust wrote: >>> Hello, >>> >>> This patch series adds support for: >>> >>> - Two new C-language-level attributes that allow to associate (to "annotate" or >>> to "tag") particular declarations and types with arbitrary strings. As >>> explained below, this is intended to be used to, for example, characterize >>> certain pointer types. >>> >>> - The conveyance of that information in the DWARF output in the form of a new >>> DIE: DW_TAG_GNU_annotation. >>> >>> - The conveyance of that information in the BTF output in the form of two new >>> kinds of BTF objects: BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG. >>> >>> All of these facilities are being added to the eBPF ecosystem, and support for >>> them exists in some form in LLVM. >>> >>> Purpose >>> ======= >>> >>> 1) Addition of C-family language constructs (attributes) to specify free-text >>> tags on certain language elements, such as struct fields. >>> >>> The purpose of these annotations is to provide additional information about >>> types, variables, and function parameters of interest to the kernel. A >>> driving use case is to tag pointer types within the linux kernel and eBPF >>> programs with additional semantic information, such as '__user' or '__rcu'. >>> >>> For example, consider the linux kernel function do_execve with the >>> following declaration: >>> >>> static int do_execve(struct filename *filename, >>> const char __user *const __user *__argv, >>> const char __user *const __user *__envp); >>> >>> Here, __user could be defined with these annotations to record semantic >>> information about the pointer parameters (e.g., they are user-provided) in >>> DWARF and BTF information. Other kernel facilites such as the eBPF verifier >>> can read the tags and make use of the information. >>> >>> 2) Conveying the tags in the generated DWARF debug info. >>> >>> The main motivation for emitting the tags in DWARF is that the Linux kernel >>> generates its BTF information via pahole, using DWARF as a source: >>> >>> +--------+ BTF BTF +----------+ >>> | pahole |-------> vmlinux.btf ------->| verifier | >>> +--------+ +----------+ >>> ^ ^ >>> | | >>> DWARF | BTF | >>> | | >>> vmlinux +-------------+ >>> module1.ko | BPF program | >>> module2.ko +-------------+ >>> ... >>> >>> This is because: >>> >>> a) Unlike GCC, LLVM will only generate BTF for BPF programs. >>> >>> b) GCC can generate BTF for whatever target with -gbtf, but there is no >>> support for linking/deduplicating BTF in the linker. >>> >>> In the scenario above, the verifier needs access to the pointer tags of >>> both the kernel types/declarations (conveyed in the DWARF and translated >>> to BTF by pahole) and those of the BPF program (available directly in BTF). >>> >>> Another motivation for having the tag information in DWARF, unrelated to >>> BPF and BTF, is that the drgn project (another DWARF consumer) also wants >>> to benefit from these tags in order to differentiate between different >>> kinds of pointers in the kernel. >>> >>> 3) Conveying the tags in the generated BTF debug info. >>> >>> This is easy: the main purpose of having this info in BTF is for the >>> compiled eBPF programs. The kernel verifier can then access the tags >>> of pointers used by the eBPF programs. >>> >>> >>> For more information about these tags and the motivation behind them, please >>> refer to the following linux kernel discussions: >>> >>> https://lore.kernel.org/bpf/20210914223004.244411-1-yhs@fb.com/ >>> https://lore.kernel.org/bpf/20211012164838.3345699-1-yhs@fb.com/ >>> https://lore.kernel.org/bpf/20211112012604.1504583-1-yhs@fb.com/ >>> >>> >>> Implementation Overview >>> ======================= >>> >>> To enable these annotations, two new C language attributes are added: >>> __attribute__((debug_annotate_decl("foo"))) and >>> __attribute__((debug_annotate_type("bar"))). Both attributes accept a single >>> arbitrary string constant argument, which will be recorded in the generated >>> DWARF and/or BTF debug information. They have no effect on code generation. >>> >>> Note that we are not using the same attribute names as LLVM (btf_decl_tag and >>> btf_type_tag, respectively). While these attributes are functionally very >>> similar, they have grown beyond purely BTF-specific uses, so inclusion of "btf" >>> in the attribute name seems misleading. >>> >>> DWARF support is enabled via a new DW_TAG_GNU_annotation. When generating DWARF, >>> declarations and types will be checked for the corresponding attributes. If >>> present, a DW_TAG_GNU_annotation DIE will be created as a child of the DIE for >>> the annotated type or declaration, one for each tag. These DIEs link the >>> arbitrary tag value to the item they annotate. >>> >>> For example, the following variable declaration: >>> >>> #define __typetag1 __attribute__((debug_annotate_type ("typetag1"))) >>> >>> #define __decltag1 __attribute__((debug_annotate_decl ("decltag1"))) >>> #define __decltag2 __attribute__((debug_annotate_decl ("decltag2"))) >>> >>> int * __typetag1 x __decltag1 __decltag2; >> >> Based on the above example >> static int do_execve(struct filename *filename, >> const char __user *const __user *__argv, >> const char __user *const __user *__envp); >> >> Should the above example should be the below? >> int __typetag1 * x __decltag1 __decltag2 >> > > This example is not related to the one above. It is just meant to > show the behavior of both attributes. My apologies for not making > that clear. Okay, it should be fine if the dwarf debug_info is shown. > >>> >>> Produces the following DWARF information: >>> >>> <1><1e>: Abbrev Number: 3 (DW_TAG_variable) >>> <1f> DW_AT_name : x >>> <21> DW_AT_decl_file : 1 >>> <22> DW_AT_decl_line : 7 >>> <23> DW_AT_decl_column : 18 >>> <24> DW_AT_type : <0x49> >>> <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) >>> <32> DW_AT_sibling : <0x49> >>> <2><36>: Abbrev Number: 1 (User TAG value: 0x6000) >>> <37> DW_AT_name : (indirect string, offset: 0xd6): debug_annotate_decl >>> <3b> DW_AT_const_value : (indirect string, offset: 0xcd): decltag2 >>> <2><3f>: Abbrev Number: 1 (User TAG value: 0x6000) >>> <40> DW_AT_name : (indirect string, offset: 0xd6): debug_annotate_decl >>> <44> DW_AT_const_value : (indirect string, offset: 0x0): decltag1 >>> <2><48>: Abbrev Number: 0 >>> <1><49>: Abbrev Number: 4 (DW_TAG_pointer_type) >>> <4a> DW_AT_byte_size : 8 >>> <4b> DW_AT_type : <0x5d> >>> <4f> DW_AT_sibling : <0x5d> >>> <2><53>: Abbrev Number: 1 (User TAG value: 0x6000) >>> <54> DW_AT_name : (indirect string, offset: 0x9): debug_annotate_type >>> <58> DW_AT_const_value : (indirect string, offset: 0x1d): typetag1 >>> <2><5c>: Abbrev Number: 0 >>> <1><5d>: Abbrev Number: 5 (DW_TAG_base_type) >>> <5e> DW_AT_byte_size : 4 >>> <5f> DW_AT_encoding : 5 (signed) >>> <60> DW_AT_name : int >>> <1><64>: Abbrev Number: 0 This shows the info in .debug_abbrev. What I mean is to show the related info in .debug_info section which seems more useful to understand the relationships between different tags. Maybe this is due to that I am not fully understanding what <1>/<2> means in <1><49> and <2><53> etc. >> >> Maybe you can also show what dwarf debug_info looks like > I am not sure what you mean. This is the .debug_info section as output > by readelf -w. I did trim some information not relevant to the discussion > such as the DW_TAG_compile_unit DIE, for brevity. > >> >>> >>> In the case of BTF, the annotations are recorded in two type kinds recently >>> added to the BTF specification: BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG. >>> The above example declaration prodcues the following BTF information: >>> >>> [1] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED >>> [2] PTR '(anon)' type_id=3 >>> [3] TYPE_TAG 'typetag1' type_id=1 >>> [4] DECL_TAG 'decltag1' type_id=6 component_idx=-1 >>> [5] DECL_TAG 'decltag2' type_id=6 component_idx=-1 >>> [6] VAR 'x' type_id=2, linkage=global >>> [7] DATASEC '.bss' size=0 vlen=1 >>> type_id=6 offset=0 size=8 (VAR 'x') >>> >>> >> [...]