From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by sourceware.org (Postfix) with ESMTPS id 4C7E43858401 for ; Tue, 24 Aug 2021 17:06:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4C7E43858401 Received: from pps.filterd (m0246632.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.1.2/8.16.0.43) with SMTP id 17OGGHH5030398; Tue, 24 Aug 2021 17:06:57 GMT Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by mx0b-00069f02.pphosted.com with ESMTP id 3amv679ht2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 24 Aug 2021 17:06:57 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 17OH5TdX011461; Tue, 24 Aug 2021 17:06:56 GMT Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2174.outbound.protection.outlook.com [104.47.59.174]) by aserp3030.oracle.com with ESMTP id 3ajqhey8xp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 24 Aug 2021 17:06:56 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i18rxG5qorKpGA2mbtrmT0YioF9WDIeMpCv3rVLjV8Kz3Lfe4P9YAFKHXrRA3GMWYa+VjnrG1qFkYAU5xv3mJfOjsuefB0oPgQ4HEyyldlSrpRAS1K8yW8lEIm3ybGxUE4CB/xA2Vj4xU+y+Z6w1hb9kRIFoQx/XKIwKjDIP5aHDZ6ZqD7wJszs3qBQ3D3oNdZrk2qxeymbgfywrkTHw9JpsHGZD5c7bjVqS2NwprRCzRkTQZ+7vFeHFM/16gE8ZLsiE3/h3xkABLmw9E0GbQw83PKbvqUR8OZo4T22ZTF+9zAkMniiwNQ4fLL15jsFpRfa7csKhsJRwm8c3JrNISQ== 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=oweiOTemuDGrEU68QsmULiquvWi1rk3q/n7peX6JkWs=; b=Gcky8fV6v46W6ZWiSas4tDeAOhtKwTZ0PciL1eOp6j13EGWtbKz4WBLkb2R4I2hA+9bVHBbrugaLjmUQIMASV0ynXUF9+bhKCuHHLXBmWmdhlU8OTmHSb4joEgexJfIZty9C0aW8eJ6+PF8+CUsGNhbseY/xo4DYAiKt/JbUc3Rz2GfIBRmLQykiJt0FVfJut8jNLApJiBdUwmjEeIu/W1PQ9aaXeKJaylJELsmp+/83tEZbVtTFJYdq9yo+7W/gROqs0St8CfHheuAHbOuXJaKEl9laMJFrSDfKmBkqzqRZcUH16fJcf610R1dAa230Wpf+ueH2tx1IyMMekXYf1w== 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 MWHPR1001MB2158.namprd10.prod.outlook.com (2603:10b6:301:2d::17) by CO1PR10MB4466.namprd10.prod.outlook.com (2603:10b6:303:9b::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.23; Tue, 24 Aug 2021 17:06:54 +0000 Received: from MWHPR1001MB2158.namprd10.prod.outlook.com ([fe80::c9ba:5127:fa3f:45cb]) by MWHPR1001MB2158.namprd10.prod.outlook.com ([fe80::c9ba:5127:fa3f:45cb%4]) with mapi id 15.20.4436.025; Tue, 24 Aug 2021 17:06:54 +0000 Subject: Re: [PATCH, V2 2/3] targhooks: New target hook for CTF/BTF debug info emission To: Richard Biener Cc: GCC Patches , David Faust 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> From: Indu Bhagat Message-ID: <24a1be82-bae8-d5d0-4022-822bc48a9a3a@oracle.com> Date: Tue, 24 Aug 2021 10:06:49 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SN7PR04CA0107.namprd04.prod.outlook.com (2603:10b6:806:122::22) To MWHPR1001MB2158.namprd10.prod.outlook.com (2603:10b6:301:2d::17) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [IPv6:2606:b400:2001:93:8000::b6e] (2606:b400:8004:44::1c) by SN7PR04CA0107.namprd04.prod.outlook.com (2603:10b6:806:122::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19 via Frontend Transport; Tue, 24 Aug 2021 17:06:53 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 96c0eb94-b086-4a89-e935-08d967219295 X-MS-TrafficTypeDiagnostic: CO1PR10MB4466: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6430; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: YWGSeDBlN6Lsztracm5YkgYNvTvav0WjYxECg53r66c36405TkVBtUBkVxTRVH6t22fw+lJRsjv78IGPZUrSwFWG/Gqm3MaAvY4qnorQkljmbaC2S8cn6YWS63FXgTp+y5ggFN2ndXU58hEAml3/cdjjHdBBhdN9zCu2H08HGm6bGvs+VWsSx827ALHzRlSFupDgL6omXcJx07kvgOFvv3BRK876eEO+AHCyRWAG/rXSjayyJIfx09cUL9yMp0ndT5UM9hiTIo+b3GMVknFTgq5BJvZVRLy7GIsTEUDJ0K94Z54iOWj+Jhs4GfevvxL+xq23WoNBHWGGFxORv1rEOBPd8jAF/nqB0gtdWJcYXPfNP8s4NsPNFTRB/9S9YNUbiuODPSQVEDBer/93lr374jLwkqNC+f005Ynpo15HZFsUxhmZI5LRR93iZCHogZbc/3/oG2Uzvr/3DdbcvuNxIlsJ8ijnuIf0MuNqXG8O1mv6k/cugyl8liSby9OHkWUaQ7DbfMTN2l71H+cHElzGkGMI9JZYMCC0xlMV7t18ZQivEsecI6JJVdQInnvqhoyAzv+OaBagmOLnRHj2iSagy/FCfP2pjsJ13zaSCLKC+yGDkBELgTGhpaJXXJOG9mqPFlsLmh9hDDhDP6slQwqhxRI5uGkR9a8xneutdbUXaMpVJLmewyk78lB1DcHjLevDVwgG+Y+a9MoWRcqqyHVLbDY/RG+xBD3nXpP4rz0gNM4= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR1001MB2158.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(39860400002)(366004)(136003)(346002)(396003)(478600001)(6486002)(5660300002)(31696002)(186003)(8676002)(38100700002)(8936002)(31686004)(4326008)(36756003)(6916009)(2906002)(44832011)(2616005)(316002)(66556008)(6666004)(53546011)(66476007)(83380400001)(86362001)(54906003)(66946007)(107886003)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?K201aTh6ZFF1S2RnRHlndStKejFFYzFPNDQwRzBmSDNuRm91OHFQN1Z1NG1P?= =?utf-8?B?Ym94TE1QcDd4UFpwUHM0cXFvNVQ1QkZYNFhQWWxoYmVNOWJMYWlyRG9iZ3Q1?= =?utf-8?B?NVJlUEFjUmF0VHdXSEVHVzBWN2NtL0JBaks4MDZjWGcwWUNzaC9kVnlaT3hL?= =?utf-8?B?bmQ2OUVvc05nUEpzdWcrWGM4cEhsYnd3R0RNUmZxajE4Q292eTRndm5oYThp?= =?utf-8?B?bWJsME9FcGJDc0JEMjUyVUVrb1gwL1prN2hKb2JUeDArZkcwK25SbzY4Q2N5?= =?utf-8?B?QW9BR0Z3MDA3R284ZlByeG9pcjJVZ3Q1bFJtMFBuMjlsUkI3Q2dxSzdCeFBT?= =?utf-8?B?T3NndVVNd0E0em5Xb3NCVlRMYlkwRWRXaEp5bWUvc2VuME5aK2t6eGFIMWxq?= =?utf-8?B?V0VTZkxHM25GNkFLZW4xVFVEbDQzbHJla0xxQWRLUm9kSmhSbHNQbTJSOG41?= =?utf-8?B?N2FoZWZrWGRXTElCaVZLTXlXT2J1RmJ0VFRnSUNab3hIZGZNR0RGejEvMVcx?= =?utf-8?B?V0wxeW8wNXY0cDB4Unp5V2drQ2tZWis5YkxIVHBYdXROb3V5YStrQzNoQXlJ?= =?utf-8?B?TUxQdWthZWplRzRYbndnZXNRSzYwenJrRWhLeFZ0bGN1cS9XcTYyY0RpdW5k?= =?utf-8?B?ZXlsaXl3Qk13YTZudTRYZ1RaLzBzVEhSU1pWYjMvSUwrQzFocklpUWVjb1I0?= =?utf-8?B?bzFqemwydlI0dDRBazd2T1Q4ZHRQV3Q5dVliSHR5SmVuOTZiM0JIVzdGajhs?= =?utf-8?B?VFlCa3BFVDB2NTBLUVlkNWVjNjJXWFVDRTFrSFBheHlMU1V3SExqaUdzZ2E0?= =?utf-8?B?eENDVXdPZEE5aTROTDBkVVFHNGFKWUEwWEg0TTJSaG9UMXl3Skgydm9VNzBz?= =?utf-8?B?bmxpNy9XQXhqdDFKTG9pUWFmRWNuNVFFMDZBQnhaMzJOYnVGcld2SFRrK213?= =?utf-8?B?NUg1aiswREJwSTV2MTdPU2djbHdySHNpdGx4b1VCWVhUVGIwMTdrQ3RKbW5q?= =?utf-8?B?QS9oMWR1cnNTL3B1VEpWalVwME5EME9xYUdjUDdVQi9RYkFBNGNTT28zZ2Vu?= =?utf-8?B?eVVqM2EyeXpRNGJtZlFncXgwdi9ITmcvaEV0c3ZpOWl4bUJnSUxCd0ZkVVdN?= =?utf-8?B?alNYMDg2em1zSzN3RFpsM3UwcUIwejdqWG5MRkVnQis1c0gwSGg4enRrWEs1?= =?utf-8?B?czlhMWYza0VGM2hEOGNaVld4ZmlYckZYQVNkb0I3Mmg2WGtTZ3I0bmhtdE9k?= =?utf-8?B?Si80YUFiRGZuREJFb2tnUklVeTI3RXdvcG5TR2lkYkFhejlNQnJYU2lJOWw1?= =?utf-8?B?Z3Q3S200VW1xaXE5QVJwUkxKcllxNS9JcVVBWk12emV2a1lNek8yRE8zbU14?= =?utf-8?B?dTBzWWk3WDdFV1ZQMVphaWNKT0lYVXlkNUpqQ2s2LzhTZXgrakh1SDhrbnh1?= =?utf-8?B?eHhEM2VnWG1OczhqbDJQMUg3Nk1zZHM5UnJhRkdGOVRVb3RJVkZvNEFEbTZy?= =?utf-8?B?THEvaVEwU1BWNUo3V1ZaemsxMmlLYitNM1FxeG5BMFRNdlYvRDk2K0NtNndr?= =?utf-8?B?SzVHS3hDZGVSNnVZeHNnRFRiemYrdFpLYXJmZ3lxQVZhSFdDRnFoSkZrVEtN?= =?utf-8?B?L3gyd0xZSTNHdy9SeDZLSGZvRVhIOHEyTXR0ZGUyNXdoeGRYcENabHRLMFNo?= =?utf-8?B?ZkNTRFkxU3FPZXVJd29QMS9DR3VGMzA1Nkx5dDAyRDdXejVqREdBU3h5S3oy?= =?utf-8?B?dEVkeWI2NTBvenkxY2gxcUhCY0lYbjMwUlk5VnRFZTBsZy9uNjVpUnhjMlhh?= =?utf-8?B?RG5ITnhxaXNmUkJhdk5lQT09?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 96c0eb94-b086-4a89-e935-08d967219295 X-MS-Exchange-CrossTenant-AuthSource: MWHPR1001MB2158.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Aug 2021 17:06:54.3194 (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: sHELiaONVPYSfkSa5ihsJrQOv15+7MXD9pZVMdmnoFXgweDXNKAHrhZR9q7CEOZC+eT/POJnFLH857a4hB5C5g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR10MB4466 X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10086 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 bulkscore=0 malwarescore=0 spamscore=0 adultscore=0 mlxlogscore=999 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108240113 X-Proofpoint-ORIG-GUID: dsoA40KIJ3qX-DlvdIWFZ7v-oyqccSeH X-Proofpoint-GUID: dsoA40KIJ3qX-DlvdIWFZ7v-oyqccSeH X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, MSGID_FROM_MTA_HEADER, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, 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: Tue, 24 Aug 2021 17:07:09 -0000 On 8/18/21 12:00 AM, Richard Biener wrote: > 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. > > Well. Guess that was it from my side on the topic of ranting about the > not well thought out debug format ;) > > Richard. Hello Richard, As we clarified in this thread, BTF/CO-RE format cannot be changed. What are your thoughts on this patch set now ? Is this OK ? Thanks Indu >> Thanks for reviewing and voicing your concerns. >> Indu >> >> >>> Richard.