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 56E953858D1E for ; Tue, 1 Nov 2022 22:29:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 56E953858D1E Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=meta.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=meta.com 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 2A1MKlOY018530; Tue, 1 Nov 2022 15:29:41 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meta.com; h=message-id : date : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding : mime-version; s=s2048-2021-q4; bh=8J3mH9mx7c+uczMhwkFhcsHqSJPzzynoOJ3rfSIiLD8=; b=Z7ZVhQGfyXHtXZZekiCdMSzo1CNMOv6DPrcF0aBas7k0/aiHWa2QCqKAbZs/ahyj3n1A xUQOgxjfbnPcjVchiidVorAGZuAP37s1fTBYdnOvaV6ZM8TJc8mFyitoejsnX/i1AR4F BIHh0qyVd12mOoncagx4Hs9n0vThppQR41XlDEr0h8Ruqufp1B8FJcEVu17KX1OKkXtt lrtMlfYd4WMGPo2JDNXuc9bnWkykYY1V4kInQWPc7brRzf6fGtGGzyPdGWyM2iyEF8Q+ IMndleQJk+2dtb4KTzdVWu6/qXGUx3cPikFjCB0QyhVysC5MugcYULz7OemQ+ptZfysX AA== Received: from nam04-dm6-obe.outbound.protection.outlook.com (mail-dm6nam04lp2041.outbound.protection.outlook.com [104.47.73.41]) by m0089730.ppops.net (PPS) with ESMTPS id 3kjh7e6whq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 01 Nov 2022 15:29:41 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZP/5unzUN29+KWYb18py7xTB+cSnM1Hq9Nt32jmq3QdHgEnKTyaBNuz0s0f6yEuicfo3IbykviqKIP3lRQEMAgNuSi6BwTbGMAfEFtZlrndgniEfxINMH+aeehXbK+bu74LR0XzkJw66Bz9wRP35GO+8NaBJ3VycH9mK3OxxzxxsBo/bBsWd6G6LBYy+vyRlp8Lp9o6c0t/QM41qNQgeP0xQuLhQnsQhrrXp1RCSD7//sz7JOC3B4tQCo8zUzT03qL856aX+c+y2whV8jIkIFJ1/YxxWID2Ryji9aRje5zZnxtOxSBbh8F6+mWOroiWXzYW420OUDd9RVWg0oN8yyA== 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=8J3mH9mx7c+uczMhwkFhcsHqSJPzzynoOJ3rfSIiLD8=; b=WM8hGyJG8YNQHv3unXFyQQLMHOsO1DqGiI5Z6FyABW6/I0AEqkF8xAsSDGY+ai4ceHF/InoWjP1uso80OM90Ljk5hIJit07JeCLr/wUDP4Ejeb4ylagPjbyUeBfPCyKubimJm78GpQ/TB15ZggqqPbNzzUOQa3w62x45ZHHop4c9BEouUP8KLUrbDlKoSuns+BkbkRIuLM3VRyxgLdYyqNuOSqOJed0lJXXfiw6wENLpNB9MXFNxNo1BwHYp1rhZsJLLZg2TXSGX9+795KjnNWt5hJhKUhgzIlxqY3gJpPYkOH/gOCEiUgLpIoUxvdHtlMBgnsFJNyJCNzJY/XNvJw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=meta.com; dmarc=pass action=none header.from=meta.com; dkim=pass header.d=meta.com; arc=none Received: from SN6PR1501MB2064.namprd15.prod.outlook.com (2603:10b6:805:d::27) by CY4PR15MB1336.namprd15.prod.outlook.com (2603:10b6:903:10d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5769.19; Tue, 1 Nov 2022 22:29:39 +0000 Received: from SN6PR1501MB2064.namprd15.prod.outlook.com ([fe80::1f2:1491:9990:c8e3]) by SN6PR1501MB2064.namprd15.prod.outlook.com ([fe80::1f2:1491:9990:c8e3%4]) with mapi id 15.20.5769.021; Tue, 1 Nov 2022 22:29:39 +0000 Message-ID: <043ed53f-5030-1fe5-ddce-0854e8f9801b@meta.com> Date: Tue, 1 Nov 2022 15:29:34 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH 0/9] Add debug_annotate attributes Content-Language: en-US To: David Faust , jose.marchesi@oracle.com Cc: 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> <52dcfdb6-f1b9-1986-5d10-8d6ac8c6d256@fb.com> From: Yonghong Song In-Reply-To: <52dcfdb6-f1b9-1986-5d10-8d6ac8c6d256@fb.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-ClientProxiedBy: BLAPR03CA0135.namprd03.prod.outlook.com (2603:10b6:208:32e::20) To SN6PR1501MB2064.namprd15.prod.outlook.com (2603:10b6:805:d::27) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN6PR1501MB2064:EE_|CY4PR15MB1336:EE_ X-MS-Office365-Filtering-Correlation-Id: e8035e2c-0cb0-4784-33f6-08dabc588fb2 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: W8mShUGbbno2/uHavf3ry3EDlRQinjl8e70mtVvfdqXNG5rxXLedFzB66fpYZbCjaely4YEHPj2sZDWwf2KXrU9NF7BrlZOX33ntaF+8ZHkw3NBpcMl7bFyoybeKxikeVMyavGvBeO2N/Ci1VWfHUCvIJjtMrapnfcm+2LO95GTGjr+o6e07gfCvkpGOldhg5A6xQ+W9ip5vC4hOvXQT7LRcaAfdi5w8p7GKzHbi7uM1h4khAhnT33HI7LT9ZW2dX6tPZwYLDdKgTZHO1U+TpP9/41aL5eWho387f/6SE1w1fyHntAIT1+huanCJBpBH4oz7Cntby0DxMiSA0OgivqKSFLj+hhsMibZJzRE5NYsDIR6uWrf9cSW30Te7khoY7wu/RTTSFWDW9UhjYp1JIOoNneKO/TNxzux7dNril4eJr4GZb6B0jpHx4YW/sHSEVG+T2d584VMAXjf4GoGghHtbGjEFcLtyChoP2RrJaTS+veHgqcw4Ru6zfv31WZmYkAc9EpVC8NU3G3hKOvLxmSe35A91YkArpLrfSGw2DLafII2LSoERZGT4ScI8GVzhD/8BuHgzynhYR5ITWQSo7FHa1k2ODVeRkeJygY8shscIkvxX203t0uVijuzyB2X3QNTIQkdmQIVQqld5vlXzoFuP2vlJlKSrJ2mDr7NfY7axnDnSsHYpEdTefUZ0Hgw537ocFQ1YyIAgxvWFzmV4esZY5yEipGaypgsgabPgnQEs4Slo6O2DIW1da3OqWYedrXq8DM9peaZfLaEJxCjogK/QVWluEKFCJg/KnqBtP1gfsZntlbLTFe1RgIAq1ttzgsGWyQ2c3Agl/4c6apgAryR1u45ELktLiBnrqtIBfxk= 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:(13230022)(4636009)(396003)(39860400002)(346002)(376002)(136003)(366004)(451199015)(2616005)(316002)(8676002)(186003)(66476007)(66946007)(66556008)(4326008)(36756003)(5660300002)(6512007)(53546011)(86362001)(31696002)(41300700001)(6506007)(6486002)(6666004)(966005)(8936002)(31686004)(2906002)(478600001)(83380400001)(38100700002)(43740500002)(45980500001);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aStFL2FneTFWWHFxNTNtS3JGNERaeFNVWlg3ZGZiWjF6VlgvQkVueWNjR2hB?= =?utf-8?B?MEh5OGIxL3NaNHpGNlZpd2p1eTFLNXZCamM1ZDJWS0Q1ZU0veDRQTDd5M1JD?= =?utf-8?B?VE91NWE4VkVRWDZUWlZhci8xcVNBYjBHWjBLdzUrMHBvSU5oWVFYQ1o1ZGdh?= =?utf-8?B?eHprNk5PNkMvTDdBVlN0QVlOKzRUenlROHdGSWkwb0tNNGFjWjE0RGxtWkkw?= =?utf-8?B?NnoxejUrOG4wNzNkUVgxbHJyT3gydmhHdVI1a2NVSGQxY29KK1ppQTB3U3lk?= =?utf-8?B?YjQrTTNReEVTN0xmejJiM0h5SkxCQ0ljQks1SHJDNE5zclYwd0JuQWM0Yisw?= =?utf-8?B?NzV2cEQzaVBKZWt2eG9oSWp1Um9sakhUTmtXZTZnRUhsM00wNmcrVVp5Um1i?= =?utf-8?B?UTR4M2lXZXpGUnlLWWV6RS95Wm5hM1B1RUxrRGFUMEFtb1l0MTFtQXY2NmF4?= =?utf-8?B?enFQbzUxYmhLNDVxTXJIbUZSaVlVL2pVYkwwZlg1b0RHODUwQ1g0MU1Wbyts?= =?utf-8?B?eGs1SkpzV1l5bWpEL0tBaEVaYjlsZXlXcGFPK3FBWjJYcjhSeGNXT2M3bTVv?= =?utf-8?B?WWJyb3R6TCthZkRlbGxISkxiczF4bWxoWkdGMUFMWGw3aVVqQ0Z3VzZ5Kzgx?= =?utf-8?B?QzVVUndRYUxIR3plcG40TEh4Vy9RQUZQNHYrbnh5K2xpYndkVXU4VWRpVHdZ?= =?utf-8?B?ZmFCQWxRdEVKTzRKRHR4N2FoeXdxbXNPSVJhTHV4M0E4UUl5eTI4OFJUayto?= =?utf-8?B?NDZXeWVSZmlLOWJmcXNudWNwWVltdTNHcEFrNkVFQWtnckJURHZENGdkSDZB?= =?utf-8?B?QWkyQUVkS0M0NDIzWUtWY0JJQXZNdUMrcVhpMTV1cFUwZzUxNHFyMFRQcTBt?= =?utf-8?B?YW95SzVBb2h2VXZBMWxxQUVSQnV4V3ZzODZIYmZQb2E1N0t4N2tlemROTVJa?= =?utf-8?B?cjBteCtSUDlnZ0R4RG1qN3hhRjZjTVB0dzhUSSt3ZVl5cEVQWExrWXNqQkpV?= =?utf-8?B?Y3JLbE5iMlBRNE16TWZTbmxuVlNpWU5UL3RRM0g3UUhDNHJ1R21QbERLWHk5?= =?utf-8?B?MDJjSGVQQ0h0QmZJUlB4MmtmNFhTZ1U5L2xUSHBsZDJkZ2k2eEI5aXd0ZXlS?= =?utf-8?B?NHA4ZVdoaWpwY0lvRlUrU0xJODI4RVdwWFNJNUluT1YydVpYUWV2WXp1Tkdo?= =?utf-8?B?TE5IdE9Ldmc0S2cwaElvaU1ybWlEM3dNelRtYUJ2c3pWZjhUbzR0REtqWC9t?= =?utf-8?B?dUc4Mm9ubEVabmdkSGk3R2lpSnovUmF5eG0xQSszS0hDMmtBTXRFU2F5WDFr?= =?utf-8?B?ZmY0cXBnWEZ5L21mOTExOWsyaUxKR0NiZ0dBcFZ2STczVGpLSWlmN1VVakM2?= =?utf-8?B?Ym85Wlc5VG13YTJlKzFLays3bzlWSkl0ZFdPaExUQk5EdnlPL3k4eXZ1OHRU?= =?utf-8?B?VlR2eWV2RURGSUxIUTRNVmcwTUxZMURxc2RJU3dLK1B1engxQzhKK2VUVGV6?= =?utf-8?B?OVEzeFl4cHUvZ0ZRL2RNVGxuWERuN3VMZkdteW5HeEpPVzFyVU13Vi9rTmFr?= =?utf-8?B?QVo2OHlxV21YaGlEaTZ0a2dDQzFteko3WHFXT2lTa09EMmNJSGxVK2wrNERt?= =?utf-8?B?Z3dZU0xPT05nanQwRG1nbUZGckFCdFM3YTlQV082aFo2ZGRRUkt6ODdUZFBp?= =?utf-8?B?cm5mb01GM2VqUGpXbi9ibGJxWjZOQ3l3djRSZU9FTG5LMjZSR3JKaGdtRGly?= =?utf-8?B?Ky8zQ0pHQkFOT1Q4M0ZtMzE1QlpXdmhuN05QRWJacEd1TWtCa1J5THVCV3la?= =?utf-8?B?ZEdIcjJnSkhkZVNhVjVrNThxVWNUNy9SSzVYYk0zQkowOVN3cDkwbDd3eGZ2?= =?utf-8?B?aElOY3pySVNraTlBT2JoaExpOGloR0FCWS96UUFRUWV2ZU1EM3RNdDdCWU02?= =?utf-8?B?bFIzUnJnelB1eDZlRWtLUHFocmNTQWxCZnkzTlFlMU04VlFKVERIWHZ1SDhX?= =?utf-8?B?TVFYS3RRTFdRQkduV3dnRDlrcFFBTFJTL0ZjYmx3Y1NjcTFISWVnTE9JTEhV?= =?utf-8?B?UG1FUHprdFZaU0Yyd055OUJIRGFJV2ZsaU5GMVFBKzlYUE04THloT2VWL3U3?= =?utf-8?B?enpWaWVNWWszYUNLLzVzaTgzMEVrdTNPN1FaNzBialc0Q3UwWHljNVdpRHhz?= =?utf-8?B?MWc9PQ==?= X-OriginatorOrg: meta.com X-MS-Exchange-CrossTenant-Network-Message-Id: e8035e2c-0cb0-4784-33f6-08dabc588fb2 X-MS-Exchange-CrossTenant-AuthSource: SN6PR1501MB2064.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Nov 2022 22:29:39.0466 (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: ajsdq4PrFJUMWMoS4bZoTBCCuy2M4d8TjMiRGVpMIdVOdH2BttxdMVBxWYslsHig X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR15MB1336 X-Proofpoint-ORIG-GUID: QUS-8EMTfJxARbquhqJzGnRvdZY2ZHaO X-Proofpoint-GUID: QUS-8EMTfJxARbquhqJzGnRvdZY2ZHaO Content-Transfer-Encoding: 8bit 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.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-01_10,2022-11-01_02,2022-06-22_01 X-Spam-Status: No, score=-1.5 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,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, Jose and David, Any progress on implement debug_annotate attribute in gcc? Thanks, Yonghong On 6/15/22 3:56 PM, Yonghong Song wrote: > > > 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') >>>> >>>> >>> [...]