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 9EECB385842F for ; Thu, 19 Aug 2021 14:42:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9EECB385842F Received: from pps.filterd (m0246627.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 17JESdoZ031829; Thu, 19 Aug 2021 14:42:09 GMT Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by mx0b-00069f02.pphosted.com with ESMTP id 3agu24m27v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Aug 2021 14:42:09 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 17JEavhi125384; Thu, 19 Aug 2021 14:42:08 GMT Received: from nam04-bn8-obe.outbound.protection.outlook.com (mail-bn8nam08lp2045.outbound.protection.outlook.com [104.47.74.45]) by aserp3020.oracle.com with ESMTP id 3ae5nbn0en-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Aug 2021 14:42:07 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H4DlFfn4GThHtqjs1AugXPg5lXDx6NRCcwdSm/l5ZF+tOHTQSmUZZsEFpR9GjOc74AbakXPd2tYdnfK/Rt2N+jjuVvLi7x1iXCdJycCBouY+MMjb8qN6cSpMOxTu2TAL/t/F9d25oMJzVCRvqqv/1V/F0/fewiFW4rAsv9/z0IciB3W0eg/tL/WEO4JkAsN91+QecIeLB4tgKoEeD8TNNAlDj0vKPDBgV73ocGE99oudfBE8ufyGDBn2es/l3Sg8s7Vo4wzM+7Hzs5v16gBp6v2ASTDT6J1fl/H5K/W6QE5Pb1upgX9Da1EmEdNPpcQoSLzVDiaJ5xxNSC3ZNdGxUQ== 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-SenderADCheck; bh=ROxngf9ndyBx5ZcBbrimztLjDnotbcRbJoGEslPCmPs=; b=R2WBgWHuxg6r6Y3NmvwcTDKWTriQlkCRWDLSQaDUnS4sAs761JwkIw4HbW2Q4BHBhiiJkSk1r5xCpQY5D8/pEMYCFb4GGORNQ6oRromgK+W9rk2uMSKeIbxnGT+n8S3YDByrBEDiEDTv0gTRVL91rVmREld5AgnO/twpMLWoHrk1nrzL6SYFEM+w2vCDRtHcmPJr9IEP45p8dpWjD4ayh5BnEH/k3qpqpvbmDPL8VOoeLRnEItE/CMo5RVnGqXQDUjI+X6JDA2ovZZhn6iTzhyb/Yv6ZXIB7RezL2B+tARTO78MmDz2UGlUMr7BWRw3EGMNbqpg49npbL8RibIWmmg== 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 BYAPR10MB2888.namprd10.prod.outlook.com (2603:10b6:a03:88::32) by SJ0PR10MB4511.namprd10.prod.outlook.com (2603:10b6:a03:2de::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.23; Thu, 19 Aug 2021 14:42:05 +0000 Received: from BYAPR10MB2888.namprd10.prod.outlook.com ([fe80::5d49:ec20:468e:1b77]) by BYAPR10MB2888.namprd10.prod.outlook.com ([fe80::5d49:ec20:468e:1b77%7]) with mapi id 15.20.4415.024; Thu, 19 Aug 2021 14:42:05 +0000 From: "Jose E. Marchesi" To: Richard Biener via Gcc-patches Cc: Indu Bhagat , Richard Biener Subject: Re: [PATCH, V2 2/3] targhooks: New target hook for CTF/BTF debug info emission References: <1628124628-28706-1-git-send-email-indu.bhagat@oracle.com> <1628124628-28706-3-git-send-email-indu.bhagat@oracle.com> <85d5d4ff-a65d-03ab-d888-493fbd7f451b@oracle.com> Date: Thu, 19 Aug 2021 16:41:59 +0200 In-Reply-To: (Richard Biener via Gcc-patches's message of "Wed, 18 Aug 2021 09:00:28 +0200") Message-ID: <87lf4xzebs.fsf@oracle.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0496.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1ab::15) To BYAPR10MB2888.namprd10.prod.outlook.com (2603:10b6:a03:88::32) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from termi.oracle.com (141.143.193.71) by LO4P123CA0496.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1ab::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19 via Frontend Transport; Thu, 19 Aug 2021 14:42:04 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fb2c8b3f-63b6-4090-1bfb-08d9631f8388 X-MS-TrafficTypeDiagnostic: SJ0PR10MB4511: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:5797; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: IqOxvSrrzT/jbvaSnCguTtbCuPhSSHBA8Tm9xGfNeCJZFI7qn2Kcx6jFt+SUvad/FhAbaaMtA76qHE9aDHEA2Tnz8K3tCA0BlNtkEkBq//b7VXULU6vGZMTssEiBFA6gC8Q9cZehBLK/7Mt+/hJiy/OJ3fuoKJjV2DfJJ4lLGghKpZT5vh9DR89xl53vuhGlLFgvF42eSzLZvE82bN4gvxRlFrzWM98Jb2HzC0GX4rTjV4mOIyrGKEqalMnN2iES3x77K4aTuxvk9Dk0p+E16/SNV+HNQAL7+ZSez473ca5yL/AB1MdtItWrvzyKwu/D3zQqf3me0pX7CfeDOmIuU000TzPJ4WjaclDQsQq57soBZEkFUzRgPktxBSnOWgP9DpzsO1oVYpgEmUbZpOTCXrLwUDq42BM+xaJaT62X1ApRJlfSnr4vPcRKeSse45ny73m6l7VggJxGGaKGNLq+Lhxn7ySBIHMd0zd+U+4sSA5cdn7eilrD+zV/JBR1uiC5SzEkZrOMfPWhz7fNUXCFJ7KsUkRCh6su6AdbEBxqGt9/Uu+k23HY8HVDM+eNKX4rCEBId0ohMPFIIlXPPlUl9G7kqnsZ5yekjxnDUFsecDQGiGSc1B2WSJ9evHIEdUR2vSZMPBtnfINkhd9fHDfKINq3hiN80bJxQ/v9fqXx7G1WZc6Aa4UNmU7xUjC1Prdof6d64aRPMzFafqd58JNxgQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR10MB2888.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(376002)(396003)(346002)(366004)(39860400002)(2906002)(38350700002)(7696005)(86362001)(956004)(316002)(52116002)(4326008)(5660300002)(54906003)(186003)(66556008)(2616005)(38100700002)(66476007)(66946007)(6666004)(478600001)(6486002)(36756003)(83380400001)(8936002)(8676002)(53546011)(26005)(6916009); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?7AoliQoKHyqM8AmAHMpZKxd7qASRQYcbJJ3/8Pro9YhOMTFUbl5rv3ZQZ7Hx?= =?us-ascii?Q?BnaTe/NTdgmuXmUsgsQxJkSXLoRfG2Q8q6Z4AV898qYlLTf7ibP7OgvFcAmh?= =?us-ascii?Q?L2ieYQylZ/fuiKR3tdMf2al6lXQNzHDEYBugZHKgfuA0KA9BlQHZe4G9JMZ5?= =?us-ascii?Q?1VWDJr1e8H8ZAkKMNUm3a2Jim/cmCFQ0HjDPN/1sRt6VJMAqrGta6FstpbH+?= =?us-ascii?Q?4cbV7bMqi/zcJYRtpsH0S1B9IrFBLbr7t4VS8fparcpy+FDovz6sv8OXs54w?= =?us-ascii?Q?zYUAanuKP4uJDYVnXvggbeetuHIMav1ZflLbfPZ/PoqW3I0YKgrkjUUq26xh?= =?us-ascii?Q?krGahLflXGBgLpG8gnLE2LFlR/TyvVIKgAfPnU12SEDBogfmlbhzx8uP+5av?= =?us-ascii?Q?6UVhFk7syHnxgGDD9xg2L/nwgEz6w1WxG/rYjUmJpX46IzyaKI3FiPUix6IW?= =?us-ascii?Q?2h3rpVUvIYCNv1hC1Ihly0yE0zdspxPiNDLR60p6atvL1oyYoDZgwIXw5rxG?= =?us-ascii?Q?APhFhEiI7QDQNadh94j6kImPKgowBiFZjpyTF0LiPfKQD6Iw4XjCF01Qg9dy?= =?us-ascii?Q?JZ/vvnDXoII37RvZqJSMWrh5+Q0lg/wIhCN2frCaSaWP8CPu5pJiwLhpFdna?= =?us-ascii?Q?wHO3rFlz8ZJ2yK8tynHbSMtgH7VGHf3DPswYy2bwS4d06yeqcYIlYP1Ogzlf?= =?us-ascii?Q?8E+K7GvaQR1SgVtq78y9A7RCe2siUMITPFOuEoO+HKy0dsofXKl1AXlAgMFh?= =?us-ascii?Q?sJRwJ3jw2OT7PHkGBF7lCVzCBb97Xn0gX2C7yf898km3cmEqaWln7CAeWoJf?= =?us-ascii?Q?2cWqGMu0179oSX2tGjxpQRO3aaXFtdwFXlg3S4u6dyIRuCJuSg4x8uJJdAoH?= =?us-ascii?Q?//5u0r9wmW8vyjYhue5S/ZKUda+XF/GM1755h+5ivcdVvNJirfgpsXzgM6Ay?= =?us-ascii?Q?478fcnVlk1t9FmieMAIfXUDEAzWKFHtEA/ROWLgUFUFRUo5BWnqoU4ulG+Wk?= =?us-ascii?Q?0cK3a9nVjs1Y54WykGj9c4QhgsM+SIriVZ/W7Ckmw0LiET9215r1SKIo+3Go?= =?us-ascii?Q?pHe5H1zr5YPltGWBzeCQX23wISlBjjcMz2NvKlYdujGduqjo6TNIBQysd+Mh?= =?us-ascii?Q?SZBm+Bevr7z9gC5nzVwZSgtEa3TsG+rxd2i7RjMXNT5nbk3X35ulW81Ql/+2?= =?us-ascii?Q?F16VrXBO4QXL2DR0M9jXyhyoKpc9KXRuQ+YQja4sZMqW8NelvV9d8AcXSbVD?= =?us-ascii?Q?YKP3SXLzFlg8QGMA3iSDt2el4BbYxdQLYEe/TYgkawylQe8NfwgD7Maa8iDj?= =?us-ascii?Q?BsYuBennKnQXx2B2rCk43xMi?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: fb2c8b3f-63b6-4090-1bfb-08d9631f8388 X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB2888.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Aug 2021 14:42:05.4445 (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: z4o8AVumAda+M/SveBt66rOtJZZVFe9xnW9d0wRCUeatDjnxW3HMVD3WASPtzPu6QEay8CnLlkbyj1nyiQu7SJQ1B5kWTiCG+1t3rp8NSxk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR10MB4511 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=10081 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 bulkscore=0 suspectscore=0 mlxlogscore=999 phishscore=0 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108190085 X-Proofpoint-GUID: bHpsVfb-E10z0t_zRD51LoupcAhbzmc8 X-Proofpoint-ORIG-GUID: bHpsVfb-E10z0t_zRD51LoupcAhbzmc8 X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, MSGID_FROM_MTA_HEADER, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_BL, RCVD_IN_MSPIKE_L3, SPF_HELO_NONE, SPF_NONE, TXREP 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, 19 Aug 2021 14:42:22 -0000 > On Tue, Aug 17, 2021 at 7:26 PM Indu Bhagat wrote: >> >> On 8/17/21 1:04 AM, Richard Biener wrote: >> > On Mon, Aug 16, 2021 at 7:39 PM Indu Bhagat wrote: >> >> >> >> On 8/10/21 4:54 AM, Richard Biener wrote: >> >>> On Thu, Aug 5, 2021 at 2:52 AM Indu Bhagat via Gcc-patches >> >>> wrote: >> >>>> >> >>>> This patch adds a new target hook to detect if the CTF container can allow the >> >>>> emission of CTF/BTF debug info at DWARF debug info early finish time. Some >> >>>> backends, e.g., BPF when generating code for CO-RE usecase, may need to emit >> >>>> the CTF/BTF debug info sections around the time when late DWARF debug is >> >>>> finalized (dwarf2out_finish). >> >>> >> >>> Without looking at the dwarf2out.c usage in the next patch - I think >> >>> the CTF part >> >>> should be always emitted from dwarf2out_early_finish, the "hooks" should somehow >> >>> arrange for the alternate output specific data to be preserved until >> >>> dwarf2out_finish >> >>> time so the late BTF data can be emitted from there. >> >>> >> >>> Lumping everything together now just makes it harder to see what info >> >>> is required >> >>> to persist and thus make LTO support more intrusive than necessary. >> >> >> >> In principle, I agree the approach to split generate/emit CTF/BTF like >> >> you mention is ideal. But, the BTF CO-RE relocations format is such >> >> that the .BTF section cannot be finalized until .BTF.ext contents are >> >> all fully known (David Faust summarizes this issue in the other thread >> >> "[PATCH, V2 3/3] dwarf2out: Emit BTF in dwarf2out_finish for BPF CO-RE >> >> usecase".) >> >> >> >> In summary, the .BTF.ext section refers to strings in the .BTF section. >> >> These strings are added at the time the CO-RE relocations are added. >> >> Recall that the .BTF section's header has information about the .BTF >> >> string table start offset and length. So, this means the "CTF part" (or >> >> the .BTF section) cannot simply be emitted in the dwarf2out_early_finish >> >> because it's not ready yet. If it is still unclear, please let me know. >> >> >> >> My judgement here is that the BTF format itself is not amenable to split >> >> early/late emission like DWARF. BTF has no linker support yet either. >> > >> > But are the strings used for the CO-RE relocations not all present already? >> > Or does the "CTF part" have only "foo", "bar" and "baz" while the CO-RE >> > part wants to output sth like "foo->bar.baz" (which IMHO would be quite >> > stupid also for size purposes)? >> > >> >> Yes, the latter ("foo->bar.baz") is closer to what the format does for >> CO-RE relocations! >> >> > That said, fix the format. >> > >> > Alternatively hand the CO-RE part its own string table (what's the fuss >> > with re-using the CTF string table if there's nothing to share ...) >> > >> >> BTF and .BTF.ext formats are specified already by implementations in the >> kernel, libbpf, and LLVM. For that matter, I should add BPF CO-RE to the >> mix and say that BPF CO-RE capability _and_ .BTF/.BTF.ext debug formats >> have been defined already by the BPF kernel developers/associated >> entities. At this time, we as GCC developers simply extending the BPF >> backend/BTF generation support in GCC, cannot fix the format. That ship >> has sailed. > > Hmm, well. How about emitting .BTF.ext.string from GCC and have the linker > merge the .BTF.ext.string section with the CTF string section then? You can't > really say "the ship has sailed" if I read the CTF webpage - there seems to be > many format changes planned. Unfortunately we have little (if any) influence in the design of BPF, BTF and CO-RE. All of which have been designed and is being evolved by the kernel people. CTF, on the other hand, is unrelated to CO-RE, and we are definitely keeping LTO in mind when designing the extra extensions (like the backtraces support) that need input from the compiler backends. > Well. Guess that was it from my side on the topic of ranting about the > not well thought out debug format ;) Trust me, we feel you ;)