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 D73963858D1E for ; Tue, 4 Oct 2022 05:16:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D73963858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=oracle.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=oracle.com Received: from pps.filterd (m0246632.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 29443wSC007801; Tue, 4 Oct 2022 05:16:45 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=message-id : date : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2022-7-12; bh=znlgnguBh1tZw35CH/97tACGq6J0oXKSuXV8cFAvVz4=; b=TyQ4Dvo8zeEGPyF4Bv8/2PAEBsVH/KaGK83ay+N0UFyLNO64fNSWqcqDEOS4amH0CYp8 xq0S8h76zy5NmQ4/ykXsRO3Ovb9uRefK5G8koV2dBVOTlnat58K5v8Hp6gBJZSx7AckI DSAv6p6Chb7TGP/3ydasyjp/BH06Ge/zNsIa9tWC4O5jrjwxW01lGW6nlW7El7ayiJcS aR4U39GQHgaMgXHbyCRRfNkY2bByKPF660XfEZittRQ48DftuYy/hndtKvQOBOq6oZ1v r0P8t9aZ9C4bE5Y1+O3f+EWPzd6WJFElII+FA1ZNakNHXzFUogI4eKS7UDYpygei/106 Ig== Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta03.appoci.oracle.com [138.1.37.129]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3jxd5tdba8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 04 Oct 2022 05:16:45 +0000 Received: from pps.filterd (phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (8.17.1.5/8.17.1.5) with ESMTP id 2943ZEpn008261; Tue, 4 Oct 2022 05:16:44 GMT Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2101.outbound.protection.outlook.com [104.47.58.101]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 3jxc04381c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 04 Oct 2022 05:16:44 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SqvDdqbJbeyJ/CfZQDqjlUPmYAc7Uyfd4B+5dbNUc1YibuRvcQO7v0xflQxA/NpFSO0nUq2dkcv1wPabO0aAoc40NmkqyOj/4yQ3E3OEOvGQ+8trc7kC6v0A6Xz/Ou1h7SmuoOhYMK/Q+rT9d9Fybt7ppShAIldIpHSW9cgNdSVWRHcsgnuKuUk3FqxrJgqTKl8ZGFKk18JppsjQTqE3q+cQXh6CETlzrXhiT/vLY3jA3at7dCNjfCjnO8SJgCGU2bLlt/T8DxfnvXBWbsd70dpO4dNEH6PSF1BpCmLJygpPHPGR1JdBP25Vy2r10GH8/1tfkhOqCn9QiSDc0IRIhQ== 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=znlgnguBh1tZw35CH/97tACGq6J0oXKSuXV8cFAvVz4=; b=W3stg3p9uE8Fh3acoGEv9c8wFZcCye4FPoCsOg0aHN/foJ62ibmpdckXZWVPA+yTUyAgYxxIPXKOy3q+Y7ttTRRWPIqUSSfphGaWIrPT36ZduiUH5JhWyl2gF+KLvp4zm3N81s48nng2imf+kt+ETUF6MuyIe1bVkzYNSLVUr4MMZqnx70cuxUWQ0qhx0JQ6XiXkhOs2iRZwDyToNu79DKg5q8trYIw27n2XI64pgEM+yV5RdPbTl5plngzR15berBVpRxMPvadQXHhVOODHltJL7cF+zQ/p81cXFlay2mF20nVNQfxtDbDM4Id0aCYoL/N3jTMc1cUWrROOdKQvQA== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=znlgnguBh1tZw35CH/97tACGq6J0oXKSuXV8cFAvVz4=; b=FD8l2r+X6kBq4LR3jOb9Zflf2J9xF03FY8C636IqopUWBfAtrXp3jOurotUUIBw7SbXen2WoSyHqaWv5JTBE76jY24PCb1e3F+GktPmE6vsA3VeSENZfXmPduHt2Sow7xQTeJvE4ORhtioqFwny+BzpGZbo2Y6AlmSjxG89n3kw= Received: from MWHPR1001MB2158.namprd10.prod.outlook.com (2603:10b6:301:2d::17) by MN0PR10MB5960.namprd10.prod.outlook.com (2603:10b6:208:3cc::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.20; Tue, 4 Oct 2022 05:16:42 +0000 Received: from MWHPR1001MB2158.namprd10.prod.outlook.com ([fe80::80a7:f7f3:4303:54e4]) by MWHPR1001MB2158.namprd10.prod.outlook.com ([fe80::80a7:f7f3:4303:54e4%5]) with mapi id 15.20.5676.017; Tue, 4 Oct 2022 05:16:42 +0000 Message-ID: <186042dd-15f1-7d0b-abf4-020201d65b2e@oracle.com> Date: Mon, 3 Oct 2022 22:16:39 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: [PATCH,V1 00/14] Definition and support for SFrame unwind format Content-Language: en-US To: Jan Beulich Cc: binutils@sourceware.org References: <20220930000440.1672106-1-indu.bhagat@oracle.com> From: Indu Bhagat In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MW3PR06CA0021.namprd06.prod.outlook.com (2603:10b6:303:2a::26) To MWHPR1001MB2158.namprd10.prod.outlook.com (2603:10b6:301:2d::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWHPR1001MB2158:EE_|MN0PR10MB5960:EE_ X-MS-Office365-Filtering-Correlation-Id: 8d1d8ce3-7811-4eb9-bd42-08daa5c79f66 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: O++APVrYsCCUWPl1Ja7bR1JlqueYYQN7vGaITpt1mG1umKOXAU03ig/kmBSoc8ZsU8CMlEsBEOGS1YmXDR8MJ3C2Z/88s0JAB5/O2pEPKO4S8H+kvO1W2V0GsM2P5ebh1h1ijMQmG8gl/+7Ov1cd/riMaUTYKQO0gYXQvd8xLMqDJW4pua8JC9Rq0gSMe1rAFfNhOOyxeINYuHSzTD5hIx+jIMF7/8+Wj5hRjc0Ue6w4KVo5jUsc+ueSdlw7dpPu6J8Und00nd1spWlNoW4qHAKw0cOaLJfQR+I3kXI33N/H5S/DCJE4QGAtcmX0xd1s0pOM6k3FB06RauC9Vn4CTs55e8UO672pdwbaoZ0eVTol7H63GIlr+4rh3KSJ3zSywXkBHS5AxbALTB5+V6TFnGMuWEGWTEea3GxYr45xaeBYeVqbxiWSGd4ByvEgAzo7lsb6lFdK7WXk6qhYdrNkc3e2WX1Yba7qvi9qiJ8wQQLYVZeDT7twIvpyuPjJvSDTWt5DiUclHGRRO/FLobnJ+TjhkTBoKTKIcE3mGW0yOiDoNqAb64m0pCX0qhUVqhnBnj5HDlP1QAjkgZzEx7erHyHcklHfDs6WVV3uUoypajJGRJ+7OJcRUrPqNW0sQk8uEMUdvjnqmR0dxjVS4UnZ1mohQEKIH8rtJeKCgBhzFMhKIJBF3sX+MnV6UsRizKtFvB65oP+dAHTTwLJUr2pTz37/vTTVy6h1heyi9c6ojQgAYWiRUmSjeOMz0wz4IM0/7a1pBdVi35VM5oVP2Li7FAkYkZckFE1wRq0TJxMte6Q= 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:(13230022)(136003)(366004)(396003)(39860400002)(346002)(376002)(451199015)(66946007)(66556008)(66476007)(8936002)(4326008)(41300700001)(38100700002)(31696002)(83380400001)(86362001)(31686004)(316002)(186003)(2616005)(478600001)(6666004)(6486002)(53546011)(6506007)(26005)(6512007)(6916009)(8676002)(5660300002)(2906002)(36756003)(44832011)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dWphV0tzTzJYMWFEOEllalFJV1ZHYUhId2NVNlV1UGphQVVvQmY0VUI4YWk2?= =?utf-8?B?NUVhRDRpQ1RoZ3BFdHc5Q013QUU1S0dmc0txdEtka0ZXYldNQzlxTWM4SGRE?= =?utf-8?B?KzVjdS8zZENWdzZwdWg0S1NYam44bFFYTkZOZXY3azFYUWlTWS9MQk9Ud29M?= =?utf-8?B?L2R5cHdHYWRad1N6V0ZMd2JWVEZCRUVXMFlrSGtPSndrVFpmUzh1ekR6Z252?= =?utf-8?B?aC9mKzNRVXFRVWQ1MFh4dkZHZTUza3ZYNFdFY0dPYXIyQ0ZJMFZhaERaSWc3?= =?utf-8?B?QnRIaVJaSVlEMDQ5SFhxV2Rxa2JhOE1ZSWpWeGsyS1lqTVRLSjVvbndoc1I3?= =?utf-8?B?UnNUNUFDcGJobGpmanpJczJTYWxUekdkbDd3djdyakEyVEJmcDRYT3NnaUt3?= =?utf-8?B?RXhVVDBFbVZNL3NSMmh0REFiQlBDRkg2cVg4Zms0dHltK2QreUdHUDU3MXhn?= =?utf-8?B?dmxkZVh0eFVwWjF2TCtpcStTbUl1Vmp6UGVYV0lnVEh3ZWg5cVZNT1pwL2pk?= =?utf-8?B?T3JmL1JnUnpMdE9kZ0lmellna3JBRm1EUHV0VkNiQ1NxbGc0L0krYmsxclJp?= =?utf-8?B?cC8rT3oyNkJhWDgxS0FlblZ2VTZpbk1rZ2JWQVdOTGhyUU14V0hySzJiKzRS?= =?utf-8?B?RVFTM0JBZjdMbEl2QkgzU1dQUDZaRlIyWjA0OW95ZzI0SXpabXVPNGF0VUhK?= =?utf-8?B?Zi9mK294OXd3M01vWEZYc003ZDZjOFQ1RW51VW1JUS91TWFLblRxWXpiRmxP?= =?utf-8?B?ZXBTNGhMY2dJeVV1ckJuTG9aQngyUjVxM3NweUExbW5FQmhCOFdkeUpPNkx0?= =?utf-8?B?UFdJQ2hDOEVwd0RKVlhzRitZcSszQjBCbWNNNCtKd0lYem1YZVRFckVldnNK?= =?utf-8?B?N3FhL3NjelpFOTdCUFplenF3VmJxREpJVDJ1dmdBQjFCYWNwZGRxZkMzUWRU?= =?utf-8?B?L0lVR2hEeFVmM0JOSForWnhQeUFRaXhHSDN3WnJUeHRiOTBRMUppMDdtWTFV?= =?utf-8?B?bW9ONGU1T2V6RXJjNTF1bXBBcFdOeHVKeU1KbWRnQXRJTGpsQWdDS3NJTy8y?= =?utf-8?B?M3BBVmVBaVl4U3A2b3FCZW1nZm5oU0ljRlU1VDkrZzc1Rk1YOUdsYWkra2Jm?= =?utf-8?B?MFVEaWx6TlFjeWI4ZkJEKzVZUDBlUjNvSXNnV0RacjUrZ3JWQ0EzdDJDMFpY?= =?utf-8?B?akw3WEFaYWJXKzBYNytQT2hKdVlidFZsNkRKbnAxNGdJQjAzNzhmaXduay80?= =?utf-8?B?ckZWNXJvN0hIL1ZCaTRoRzZXK1FIR2hidEJQOExjM3Q2SDU5S1VuYlcyeXFH?= =?utf-8?B?N0hqSzZMa0JscHNNaEFnMEVDVURmTlp6dnozaExUT3lNYW1hUW9HUm9lTlVO?= =?utf-8?B?Z3R1MnZnaHE0L2FzOGpTVXVPZVVKWGU2ZDhJVmd2OTFyRlRkYU5NUGc5SFJj?= =?utf-8?B?OWF1d3NSUUFUQ1d1OXZhRkZmajRNUG1PdFhxeUFEdFV1NlZ0aER4QVhyQUpo?= =?utf-8?B?ejEzTEgreEljUWRFdG9ROE1QelRXSjNyRTVJUkdQL3JXN3ZQbjBQckZlZHp3?= =?utf-8?B?NGlEM0VmdVJhMFlDTko0TG5nSGNMMUpEci9NUk4vbXA4RnlwQnREeGhTcStJ?= =?utf-8?B?bWV0em00ZHRsdk5pUzFwRFpkT3F4eFdrOGozeVBnRVJObWIxNEo4OTEwczlY?= =?utf-8?B?S21LNkZHQXp6dEJGWkJqV3luMFMrZFBIUnJXaTNuVVVOL0pjTE82bkNLQmtt?= =?utf-8?B?MXQvK1MzT1pFYUVPZDlZNGFndFhYS0MyWXZFcndLZnl0K1JBR2lqWTY2dFdl?= =?utf-8?B?NVhONnlBeXVzRHN2Qko2Y2kvQVpuaWhrVDJoWFdHc29xclY2NTdHUTVROE1L?= =?utf-8?B?OHI4YnZMakUybEt6UkFaUU9XV1g3Q0hCOXE4VExSWVYwa1A1S1ZPTnc3L1NF?= =?utf-8?B?MjEvZithTEI1ZjBnTkRUMTJ1Wmp6c3pJVXh4RWVINk5BV1FaRDZzaWxmNWpT?= =?utf-8?B?cm1SSjVNMnUzVEM3Qnp3b0oyWFZkeWJMSkZiVU52WnJiKzJNRXVrWWlVNUhK?= =?utf-8?B?NmYxZTJVODRONENXSEl1MWVIckN3UzgzTThmc1Q1UjRqUFJMV0ZNbit6dXN6?= =?utf-8?Q?nnwv8cF7lUpqH23Qpj0lcT2Rz?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8d1d8ce3-7811-4eb9-bd42-08daa5c79f66 X-MS-Exchange-CrossTenant-AuthSource: MWHPR1001MB2158.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Oct 2022 05:16:41.9138 (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: 9cBSUQ2l2uThF8RExKic6rMzGsyI72J21EudF8/y5LaqFDoCCDTFe5ar+1rFGvpHyS7exMKF9zTtlbG+ALZX9Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR10MB5960 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1 definitions=2022-10-04_02,2022-09-29_03,2022-06-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 malwarescore=0 adultscore=0 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2210040033 X-Proofpoint-ORIG-GUID: 2Os2fFmG4fYDKW5MjaKQjo9T0DTlcQyQ X-Proofpoint-GUID: 2Os2fFmG4fYDKW5MjaKQjo9T0DTlcQyQ X-Spam-Status: No, score=-8.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 9/30/22 01:09, Jan Beulich wrote: > On 30.09.2022 02:04, Indu Bhagat via Binutils wrote: >> What is SFrame format and why do we need it >> ------------------------------------------- >> SFrame format is the Simple Frame format. It can be used to represent the >> minimal necessary information for backtracing. As such, it only encodes how to >> recover the CFA (based on SP/FP) and the return address (RA) for all >> instructions of a program. >> >> The format is supported on AMD64 and AARCH64 ABIs only. The information stored >> in the .sframe section is a subset of what .eh_frame can convey: .eh_frame can >> convey how to resurrect all callee-saved registers, if need be; but .sframe >> does not. > > I expect the question was asked before, but since the summary here doesn't > answer it: What about cases where the return address is stored in a > callee-saved register? You won't be able to determine its value if that > wasn't the leaf-most function in the active call chain and some inner > function saved and then modified that (presumably) GPR. The same would > likely apply if the return address was saved to some secondary stack. > > Jan Yes, this question was asked before. And thanks for asking this here. (In the context of recovering return address) As far as x86_64 and aarch64 are concerned, I *believe* SFrame can represent most ABI-conforming cases with standard stack usage (except the #exceptions noted at the end of this message): - For x86_64, the return address is saved on stack with every call instruction - For aarch64, (from the ABI doc) all "Conforming code shall construct a linked list of stack-frames. Each frame shall link to the frame of its caller by means of a frame record of two 64-bit values on the stack (independent of the data model).". So the return address is tracked as it flows from LR to stack and so on in the SFrame format. So, IIUC, the case you mention will be "non ABI conforming code", correct ? In such a case, SFrame format cannot be used as is. It will need to be extended to support such cases: - first, encode the return register per SFrame FDE (so additional few bits per FDE). - second, recover all possible return registers (i.e., all callee-saved registers per FDE) via stack offsets in every FRE as applicable. The second item will not fly in the SFrame format (atleast not in its current form); storing stack offsets explicitly like that (for a bunch of registers) will cause the unwind metadata to get quite large. If there is a high usage of non-conforming code in applications, and SFrame is still desirable for those, something needs to be done. My viewpoint here was to keep the format simple by targeting to support all ABI-conforming code. Is that reasonable ? (Posing this question to also the wider community). Now a subset your question, I believe, also intends to ask - how do you plan to support architectures/ABIs where the return address can be in any register. The answer goes back to the above-mentioned two pieces of information (needed for non ABI conforming code in context of x86_64 and aarch64) and their high cost in SFrame format. Instead, an alternative strategy could be to take compiler's help to assign a "recommended register" for return register usage in such ABIs. The SFrame format will still need extensions (but these extensions are minimal) : - an additional field in the SFrame header to designate the "recommended return register" (the same register which was used at compile time). - the new ABI marker in the SFrame header. Now if the compiler is not able to use the recommended return register for some functions, it will mean that SFrame-based backtracing will not work through those functions, hence affecting asynchronicity. I must admit that I haven't fully thought this one through, so not completely sure if such a solution work ? I think it might. re: return address was saved to some secondary stack. I need some more understanding of the issue here. I was thinking an entity higher up, like the unwinder, will have enough context to pick the appropriate stack to which the stack offsets apply; because the decision as to when to switch to a secondary stack (or not) must be a application specific property ? If you have some resources to share here, it will be helpful. Alternatively, if usage of secondary stack is specified at an ABI level, can you please provide a reference so I can take a look ? #exceptions (PS: I plan to work on these) : - .cfi_negate_ra_state handling in aarch64: if the code uses pointer signing for the return address, SFrame needs extensions to represent that. - .cfi_escape asm directives: these are also being skipped at this time. I may not be able to handle everything here, but even if we handle the most commonly occurring cases, I think we can get close. Thanks