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 CC7A93857418 for ; Wed, 11 May 2022 03:44:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CC7A93857418 Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.17.1.5/8.17.1.5) with ESMTP id 24B2gthS029905; Tue, 10 May 2022 20:44:03 -0700 Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2171.outbound.protection.outlook.com [104.47.56.171]) by m0001303.ppops.net (PPS) with ESMTPS id 3g04ksg8pe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 May 2022 20:44:02 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TvDW3VeHi9CW1HMiB5yH3LRXRkD2E2k2afuVaYcz5SSYRr2FUEA1Jhn0zB8NTb8Z0mL12jpsU1dGrYR9BR2nSv4rgve4Mv6zI+9cB7A3J4ncHsureo33YnUw19lZDXWZQag4SVQvA61F0pRRVXYG4vSthUvT8sDV6uvuLldHCh4vEzyGL+MfFRR8wKxsoc/Og5OmbkaCcHze5+l97F4+aEsCIQk/CEDtk5cYBWgaVC4sAs7CEsUJN1/0xUPQdKL2L9MUY0321i0APQNaybun0XqGYa5HPTpFT2V2BvAWWK1zFsSDzNKzUC8eDTflhg2/wv02szFvQDehVN8hLT6jMg== 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=rutM1M3u6Jw10mSy8K4BVBu13fZNDC3rypnwLmlyR54=; b=atiMMHdgtRBLH2epQQjkEY18FeOYYH+WoRX2hV27nzedOGGq8vjxnd8MDB/FY6S+S4bFKLaLS7T1I9QTCtkBXw/H0y6VgQ738tmYmH4bZzhHBe3YRfh9u0/OPv12Uyfb3VW7JvkHnHGOAdfefkUkbnk/NLTtZPS/i6OQ/87ll4quadXEsaQ0vpln9a7DH1kwJLQagzn9p8D6Ivcr3CZQgWSYITf+fC7iifodWI3yUwVSJrwBbn7iEVs9UaIwNL/3YwysqFqB5cLaxnS8ex2AWWaJjOJ6dUMflW+twMczTfzEGJjjlkZ7kPcGoCAvHqSwGOPolN5VlXW5KgOXgMYSYg== 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 DM6PR15MB2938.namprd15.prod.outlook.com (2603:10b6:5:13b::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5227.23; Wed, 11 May 2022 03:44:00 +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.5227.021; Wed, 11 May 2022 03:43:59 +0000 Message-ID: <7125844e-f538-faca-1cdf-5322492c00d9@fb.com> Date: Tue, 10 May 2022 20:43:56 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [ping2][PATCH 0/8][RFC] Support BTF decl_tag and type_tag annotations Content-Language: en-US To: David Faust Cc: gcc-patches@gcc.gnu.org, Joseph Myers References: <20220401194216.16469-1-david.faust@oracle.com> <7419ae42-55c8-87d6-2a19-74cebff51fb4@oracle.com> From: Yonghong Song In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SJ0PR13CA0081.namprd13.prod.outlook.com (2603:10b6:a03:2c4::26) 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: 832750c1-79c8-4b6f-30e3-08da33007bb0 X-MS-TrafficTypeDiagnostic: DM6PR15MB2938: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: Xup/sO2uciCHykZRpTzLu700PxawW982mOXQ/DKIc5WYT+3auBNDdtXLGamc29l/mt+DiQT3uiri29+f6Zghe35DOcEYPDXW1kBhGrh5n+PW5FTS5aB40+xSzZys7kxSteyF9k7Zq6niifas1mH5fyltodemXaVduPqTH5Yy5MT1+XuZ2ilJoVwxxfPqq9AxLbGCEuEP1y5AGoaeqzPrq/Bxzmh+NPT0UCUdEmIBe8W5f/nfhP6rfr9mUJPUc2r+by2peCokB9gvZlDnmUN4yLnYQ3BLA+ZmHF6MhGkL2bJdWeKMRzp81PN0/f6SR3d0pgZA2CpNycKhpUMgY/3sUG458ubnC+j5fNP3NRUQhsvG+yVkUmDUP4/6+0dkqkLofkx/cwG2PHbM1hfobgqtu/+pOwkLdDxdsRi6Ej9/PuKLyD3cWS9NTPU4JEwEkw4nxGD0tN5u9usWD5ZUlLX4dVQ2+FvzbYHUxdnUoe+H5Rf1+mCTZ3q3QgCIS2YYv9Vv98iq3NLG+oxk9NLrxFFSeig9K+eCwZXus4kCIjmq+XI+V8mjbJ564lpiwAX0WP44lzfaemB+56tzudnyxLqb2azqj7EcY5YaJqTX51hs5FueiAw4nK8P6B9h1+bM1WBozbfw+ayBMGGjgfuA/8qW19Uuz9ZlA0Bc81i/z7HrpnLeLC93D++JP9eX3zDxN8zhUVISDEYUGoes5K9rYj4G8eJVu4JR2aWuRYHBAEw6ypg= 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)(6486002)(86362001)(30864003)(31696002)(53546011)(6666004)(5660300002)(52116002)(6506007)(508600001)(8936002)(83380400001)(6512007)(38100700002)(2906002)(2616005)(186003)(6916009)(316002)(36756003)(31686004)(66476007)(4326008)(66556008)(66946007)(8676002)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bUYyY28zcmZsVDJqOFpOOEpySVFvcWtQZ0EzbzhORnZZZEFGU21CcmdUSXlw?= =?utf-8?B?L2R5R2JYdHdxQ2xpWlZLQW01RC81SFBMT0RnU3JrQ00wS1pUNjQ0VHUwQ1dy?= =?utf-8?B?dmhrM3JQVGRXRUJURmdHT253R0ZJeHdYcGJQa0c4RSt5WFhkVHhpSHN0ZTd0?= =?utf-8?B?dGZlWWNvL0VzVmtVMWNERGxiVmlFdHZxVEFpcjRiM1Mwd2ZDS3lJM3hnZVFu?= =?utf-8?B?RE1DOGdVekt3V3I4NFpvWmJsMTFvZXB0RWxXcmZpNVVnQ1E5Snp4QTlwUmRC?= =?utf-8?B?YnRuQnlpbkZFem5XNHBybjBCUGlkNW51WTFmZFBuekowZXZSSk03MWxYYjN2?= =?utf-8?B?Uk5TV0NpMHlaNnNtZzlHblpqWjRUTERydFNkOG9SdnVlRmpwZFBERnhVNkl2?= =?utf-8?B?T3A4RjlYODk0MkRxMmpKSGJlNURhWjJyYVZnTVFLVlV2V01wRU5XaklJVEFE?= =?utf-8?B?ZXpxZDNKcW1UTG9BZzA5UjdSNUNTUW5NU3k1TWwrTWN6Z0FRSE5nNytweXJH?= =?utf-8?B?ekxDZUxNc2VqWXNhVkUzVW03LzczL1N1V25QTDhaRUMwYlY1b0FLZUorVlhX?= =?utf-8?B?d29od0trYUhBUWw5WklFSmVJSkNTazZSUWZTTWNXY0RiTWJsUVlNd091cE5N?= =?utf-8?B?UTJTYUVZZmhHVzJQdWc4K2lsUXFuNHZ3T0dkY090b3ZMK3VieXBsdE9GRDZK?= =?utf-8?B?R3FNU1pOQUFFYm85cWhnNy9kaitkMjRyeEw1aEJrL3J2aURYQUd1MFNTOEs2?= =?utf-8?B?UFlQZ0c3KzdJbFNjL1l0MTl0QlBNa0VWZ0hwRmthbTZGZXNMZ1BWTnJpL3h1?= =?utf-8?B?bFkyWWRjRVNqWjhTdG5oa3pQSEpCVU5vNDVnVG9kWTNMMUhMVDl1OXJwbnpN?= =?utf-8?B?OStPeWQwME5tcU5RRGpTNnJvczlYT29iYlZUZWFTSmU2MnBUWW9zUW00SCs2?= =?utf-8?B?VDF4TXdQRlVtSVFMcC9KUlZHUEhJRVlhVzRRL0ZPN1UwSzFOSFljZTFGMElP?= =?utf-8?B?YW1oaERISlBQVXN6Z1RWd0k1bHhXalF4Y2lLU1dyVldMYkVhRmNEVlY4SjN6?= =?utf-8?B?WForRDl3Qm9JM3F3c0pxTksxT1l2YVJxdlVQZjFHV2RkSHlVRVZZbVR2WHFo?= =?utf-8?B?cHRyTUFmbmM5R0F6MTVTWlhaaXZlL0g2WFRmSFhIekV6VGRCVTkvTGdkOUlt?= =?utf-8?B?dmdiay91RFhSaGJPWlA4M1BaaGdnY0RNRlNSdzRsazhtaEE4MEFFN09XR0VZ?= =?utf-8?B?YkxjZHAzVVJ2SCtzaUVZMmE2bVI1ZFpBSXhlVVppaENXaGhYYXpKUFZTMENL?= =?utf-8?B?eEZoaDQ3YnQ4U2hvb3VaRXZRblNjdGtPbG83WW4xanEvcC9GY09pUXUrVE5t?= =?utf-8?B?NnE5TDlVc1RRQS94R3RyVHNlOENzVWx6NVZWZXBqaXdiSWk5eExYTEwzSHRB?= =?utf-8?B?TjBFVUU2MjJNTyt2Q0swbzRXVENTZWwyRDhjMTFUU0U1NGhrT054czlEVFEz?= =?utf-8?B?ZUZJS3RIWmFHYnJRRUtVa3did05yeFlpQ0I1NFd0VUFzSU5VaGt6S0dnUEQv?= =?utf-8?B?ZzVLVHFYME1ING16S3VlcXdFenVUUHhvbGFDdHduUS92bVFzakNPM2hMWU83?= =?utf-8?B?c2xsMzJycW43cmFVN1ZqOVFobTFIZ2UwVFNKRWVGYTR5QUhwNkdsb2U5VmR3?= =?utf-8?B?YkVKK1JmZG5aK3FXWVJOQzJDeld2NDd1MHNVMjBWUzJEMFFiUVNZeTljVDkv?= =?utf-8?B?cjBZaWNYcDMxVE9yVURkNnBzaDRzSzFjZ2hEZWRTemQ2WjFDa092aThwdS9T?= =?utf-8?B?eXdPSGo1ck1hdnhqSnJPOTE3dU9oZi9weXpMRWViQUYxSDFRTGp6dHN0dk9E?= =?utf-8?B?djhXOGV0RldPOW9seXNGL2tFQmh5bWN3ZVFzNDBTR1hoUThlZGI2K3JDbDVG?= =?utf-8?B?bHhCSnBWR3VWdFFMeTljd2ZXRkZkMytGdll5dHVFN2ZTK1F0YXkwWm91QUlP?= =?utf-8?B?elV4Nmh2MUFZNlpjc3J4T3lmS3FrUFdoN1ZQZlFZMEhvOUZ1NWJ4YThtSG56?= =?utf-8?B?VnVPZ0RkVWhtc3R6YW9FT0JBNnFSbVpBMkJGMnlJNTVjdmk3bzJBbmRzcG1K?= =?utf-8?B?RURNZExRYkhMVzBpRWNlam9MQ3RUSHh2Uk9rWDZuanJwOTU2K0QxczR3bEJu?= =?utf-8?B?c0M4emExWXNFenhVMFVSQXVURDBPSmFWZGlaZGM2RXF0Mk5Pd2pTSjlNY21o?= =?utf-8?B?emJ2QlUwc0t2cHVwVnArUnRuTnhwMWxrMitWYXpEdDZveEZTdUhiT21Iejk2?= =?utf-8?B?RC9LVzdyd3BXUVZsdW5VWmxTZUw0YkZnNElsL3FFdU8zSmd4bkxRU3p2REFG?= =?utf-8?Q?vodzA/zknUJSSYa4=3D?= X-OriginatorOrg: fb.com X-MS-Exchange-CrossTenant-Network-Message-Id: 832750c1-79c8-4b6f-30e3-08da33007bb0 X-MS-Exchange-CrossTenant-AuthSource: SN6PR1501MB2064.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2022 03:43:59.5444 (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: cKfqZM8YtpUP6sLUetapolvbPG7Nr5FHgHQLYFnRf3IqnU2clx9CwznIv1iRzNBb X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB2938 X-Proofpoint-ORIG-GUID: Ke6nE-z_v8nTBdSGIWqLUk1QoVNiQU2q X-Proofpoint-GUID: Ke6nE-z_v8nTBdSGIWqLUk1QoVNiQU2q 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-11_01,2022-05-10_01,2022-02-23_01 X-Spam-Status: No, score=-2.9 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: Wed, 11 May 2022 03:44:07 -0000 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. > >> >>> >>> 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 >>> >>>