From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 910DDC54EBE for ; Thu, 12 Jan 2023 20:54:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240443AbjALUyT (ORCPT ); Thu, 12 Jan 2023 15:54:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54386 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240408AbjALUxZ (ORCPT ); Thu, 12 Jan 2023 15:53:25 -0500 Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 953FB1C102 for ; Thu, 12 Jan 2023 12:30:35 -0800 (PST) Received: from pps.filterd (m0246632.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 30CJubYB006533; Thu, 12 Jan 2023 20:30:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=message-id : date : from : to : cc : subject : content-type : content-transfer-encoding : mime-version; s=corp-2022-7-12; bh=hbOzg7dCVSsQ6pilH3GI7ZyxGQTIzQWK5asFAAtUhgM=; b=Drk6gbQ637zqPDfykHdzrGLEuOdkMW2w4aB+xBrLJMmBzEwV5uaDR4BsFmVrxjhSx8vl a3g3+OO9JAcd4UAwUMxjXrA8hHTA40Rzf6JnyDlGLZk4SN5VX6up3OR0wQ2Wc0cuev9f 7pyxIJ4LauWU2RQjZ+BNA3ItMCb2m4mm9LCU1hy18pvAXCu47emVvaDmAF20yyWkfUGa Ia093G4livPu+GoFP8WKjRpQZDY7s3j+FDlRX7pTfxV2NJ0FJ4EyFxguE3SCbdIVhkmn mfJlV171VzVYCzsKQnwTCO54Dqk/CSj+henKk2ycvFCCTVLz92CFK/5HmBGXdEsrDGE+ rw== Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta02.appoci.oracle.com [147.154.114.232]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3my0btubt8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 12 Jan 2023 20:30:32 +0000 Received: from pps.filterd (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (8.17.1.5/8.17.1.5) with ESMTP id 30CK6rwc007584; Thu, 12 Jan 2023 20:30:31 GMT Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2168.outbound.protection.outlook.com [104.47.59.168]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 3n1k4crbx1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 12 Jan 2023 20:30:31 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b2JW9Oz67kIN9BkeMcm/BmAS/HuUtMoPyXqtlDgfth5mP+bjYlTerOSMlWp7M1BRyB+EA4KPayWMXcMIFMdI+zkculFvEBUlFvnPIfEwM5F/1OmbZajjSGgVqhqxUUpDcUd3zxozJ+4QcGTyw86RkV8efdYhfhhOyO/kDJieTcHACki/1+XjjsSb6HDzcx/wLOlNiKu6XTBM3i5DPOEEO+s8S8oy6cJTsk80Ku/7Cw9STKT3lw+e1Ml8LBQvxNFe50K7GBXCTuTplJgBUj4YwXwByPs0TqiZzFQiViov8P1fn7hVW/Kvyq+PHe9Cf0IizqCH2UbTaxL5DUSavWT6kQ== 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=hbOzg7dCVSsQ6pilH3GI7ZyxGQTIzQWK5asFAAtUhgM=; b=HVWBPN4ajDfvOFMcDnQnpHI6YGCqT+kMt798Ev8GRXJyNiYZl15XquLP6al5Jj0/z/eZdBdgrpTTp5eR7VvnGXZm9VJjtQQO+otpA1o1t/rBg8YI/LOnWi0f3joMXMdiO59euOMgVwx7JqHKzxnvpP71cTR3DwujauatH9Kg/C+aEVqg2dfxI01G1ZPEugffrkVp+7PYvpd+PgD2lTXqK06BhBKlOk0bd9r+/rj4DgkPBe8WWV2DLW0LqckXcIH7ct9XxxIWG5Ial8Hk9SHXdPsWE9CupKSRhrFAaSIUBsjUZLw6xmkDecU0WXzgXqwjkzvM2n/M3v1ciFWGGvJpgA== 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=hbOzg7dCVSsQ6pilH3GI7ZyxGQTIzQWK5asFAAtUhgM=; b=uKNEGpO3qkeS5OV+zxpRpYXmZMELPnZh4Y+kJwxClSifFxzlWgq4og8R4J6kGfyEN/nGrF+DyiFGTlImpblXmF8M4BjHAlQ5Ir/8QFJoJlvpj9eRj4qizMV4T4Yv8JIlrT7DF0OeWlDhkUDIahJZcwM8EoJS3GR+q498Slk82tE= Received: from MWHPR1001MB2158.namprd10.prod.outlook.com (2603:10b6:301:2d::17) by CH3PR10MB6809.namprd10.prod.outlook.com (2603:10b6:610:141::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6002.11; Thu, 12 Jan 2023 20:30:29 +0000 Received: from MWHPR1001MB2158.namprd10.prod.outlook.com ([fe80::14e6:a522:273f:db57]) by MWHPR1001MB2158.namprd10.prod.outlook.com ([fe80::14e6:a522:273f:db57%7]) with mapi id 15.20.6002.012; Thu, 12 Jan 2023 20:30:29 +0000 Message-ID: <7dcae1d1-b0f5-a497-a473-26a43f1b1ad6@oracle.com> Date: Thu, 12 Jan 2023 12:30:26 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Content-Language: en-US From: Indu Bhagat To: linux-toolchains@vger.kernel.org Cc: "Jose E. Marchesi" , Daan De Meyer , Kris Van Hees , Elena Zannoni Subject: Unwinding user-space programs in the kernel using SFrame format Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MW3PR05CA0016.namprd05.prod.outlook.com (2603:10b6:303:2b::21) To MWHPR1001MB2158.namprd10.prod.outlook.com (2603:10b6:301:2d::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWHPR1001MB2158:EE_|CH3PR10MB6809:EE_ X-MS-Office365-Filtering-Correlation-Id: a0cedf43-bc20-4db7-1371-08daf4dbd83e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: YICLpMYTnM/5jhQMKoGpu3rZnyYg8NgT7jGyY8X4xVM7lbE5FY/pOmzhw3QugiMtyKgXATNyr3lZnW568oLSV3fbtvhdxG8fvTgCrtsDSciMXmrUi9qtBls3dh8QCawXlmtxtiqkk31RqWVw8+UkBLcgrqdwyNFuV360F7CmXmvZ1e10nklVCOunGMZB0ziOAg+04uzOlhVY2M2iKGLZqR9rSgQwCmbYB7obi8Jt2x34UtbgMADA9Q1+Doj/pGtNM85Ae7qzuYj6mgoFZRsxevSjU9srMXDH79sG1GEC4Sm8em0aklWWhblQGu7VHRL2pm9/fgo8jKEl1IB4GY0fl0ns6sZ4g+6hc8kXE+hmftkT3bR16tRQkKz5ecOk2T4EDZM7XpUNKPc/MLnre/leZQczKdOhKPCLcc1b6dMlzauSsdloMflfa6AxYXKpk3a8d3tFyE6sftKYcIzferotYY+jVDEXfaiRG3lJWL6vEfExo7+XbRB8M+RkwsxiELwAKoMV8KbpVqepWuwKSOa8YR/7fB/z+Psuq3D+dV+06MdGafOPfNzxCbS9WZLgCG9ZDTgDxJvpkPjQrfSckROMPf8YIguQqyCnHG7fO/JHLji91XWcoJYNMw9BW3rrOOC37NyDXMjUORfMAIeAtbyzq41QwyKdwWYuSSv/47CMcwhNGSIlflmQjLuVjDwQGSUrkF7n+k41XGjSgu+fO8332etGBRnc9a4LpHXnnFWTvkXg5VRb8uyvzShQrTxKL4MJ6IM46kQdjhMUHQYvahmJPmB+1TtvC2JdWTqnsL5r8G8= 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)(366004)(136003)(346002)(376002)(396003)(39860400002)(451199015)(83380400001)(5660300002)(41300700001)(8936002)(38100700002)(36756003)(2906002)(44832011)(31696002)(86362001)(26005)(186003)(6512007)(66899015)(6506007)(6666004)(107886003)(478600001)(6486002)(31686004)(66476007)(316002)(4326008)(66556008)(6916009)(54906003)(8676002)(2616005)(66946007)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bDVxU2dEWk4wQWtQVjVadGJLS09zZDMzNmFYL1N2cDRLUHBkV1RsRWxpNVNj?= =?utf-8?B?SnRSWmI4d3g0ZHR6QTRLOGdlWURPeXpGSCtJRVlCaFhnV3ZLbis5UXJndFRy?= =?utf-8?B?bUh2UEs4TFo3QUVZOUZMQ1h3NDZOZVdQbHM1b0VPZTdWZFlqYnRiVHlqRi80?= =?utf-8?B?VjVIZjBQVk56eGd5SHRJUS9CY2FKaUsvai9sOVRpcndzanN0eWdrSSt3bklK?= =?utf-8?B?cjlEaFpoZWppRnFGK05KL2YzNXFZZUlMc1BNTS8rK0ZTVkFoRGc5QmNJLzUr?= =?utf-8?B?UlozeHM2N0lvQ1FOckJneCtvZUZTSE5KRjBnVVBDK2h0blNaYS80VnJ2cSts?= =?utf-8?B?K1hzcGhGUTg1amV6aE5vbmEzNnp2YURNVVJvMnVqaDhYVHZtakozRHlZLzVQ?= =?utf-8?B?Z1hheTk3K05teTliYVgxV2Y3Vlp2ZGRvdlFxZFBzSUtNRXljTVFrVllhZW0v?= =?utf-8?B?Tjc5ZUE4V0FsTm9QaEhSSUthYXdkbzUzWEZtKzNUa0hQejRoV2pDZHlycEtt?= =?utf-8?B?S2lTRlZvUUszcHRyWUJzV3VSOUUxN3F4VWc4SmthS0lnQVZLVlhlUktDTDZw?= =?utf-8?B?K0JsTHpWbmozTDA4ZVkrdWdaM3ZEbEtDS1ZWVktES0Vhd0o5Y0R0NWdEeWpw?= =?utf-8?B?a3JrUTlkM093U0xjNkd1NGFKNTNpckRGMi9LSUJxRDVWdmJEempEakhlWUY2?= =?utf-8?B?NW10Q0FJelpnUW5pMnljZm4vV011UGMxd1ZDeU92NmRhbmNtVmRxRHYzQTZV?= =?utf-8?B?eDBiTmNZMlh0RXpmcXk2RVkxVExKT2JnRWlxaGFuWnB4OHlTL0l3ZlhVQkFh?= =?utf-8?B?NmMrQmxiTzdNUmJNbkpwV2QzaU13aDdLQTBTb2ZIcGJ3ZGowUEVaT05SUG5j?= =?utf-8?B?WEFGUjBOcGxJdzQwTlJ4UTlYR2oySU5xSmJDdTRrZUNjdGV4Q3RLMHRINHc5?= =?utf-8?B?VkEvRk5nNXdEYStxcU4xNTJHaCsvdlNqamZ2RWtiVmxmK1hweWNKRkdmSER0?= =?utf-8?B?a2ROSFV0YVlwMDJNbXZ4MjFuTGZaUjFRaTQ4TVFZejJFaDhBbzlJMUN1eGZH?= =?utf-8?B?SnNabFh4SVpJaU5QbTZSQzkreEEvYm04NkhORHZwcHBYWFViQXdpRS96eVF2?= =?utf-8?B?K2pYZVVObENrcnNDTGFZQmhlTXBpN292ZnhhZEc0VmhlK1RtOU5EMXBVb3J1?= =?utf-8?B?bEFZN1NYTXpuY0JLNGJ2YWxVZlVDNTdHVWhNWFgvUEk2cjNmUlZ2VlgzbWlw?= =?utf-8?B?YUxvRmdmRjRnZTVxTnVMWHg4TFpUL2FXc0QxVHgyeFJnYzF4N2t3OEZoWXgz?= =?utf-8?B?TWxrWnRvK0x5a05qMFY5L1Y5VjhMUFpqSy9sNXVRMG9aZjZGTWlqbThsL2c0?= =?utf-8?B?d3FmMEtXejN3VEc1eG52TWI5clFkd1VEbGZ2UmNuZ1B3bktKdUNHMkJzVXNK?= =?utf-8?B?djFXdEt2N05oczBmcjlhWUg2SFlSem5EUzRjOWcyWU1YWTgvKzQ2dkN6R2xr?= =?utf-8?B?SW5HbkdWSlZwOTJreTg1d3MyZlpJd1Z5K215NlBVdUYrNExlWXVQcEk0cUtK?= =?utf-8?B?RUNKWGF3eTAzdzVqeGFJQ1Q1dnNjaWFhTjd1MFhmUkIyTEZDZk5TeVpwUmxG?= =?utf-8?B?Si85amNtWWw2QWI1UXNrRWlsUUtxZmpCMGhPc2FkL2N5a05td2N3TlhPa1hJ?= =?utf-8?B?YytXeE1uY3R3YTN2c3hVVSszd0tpcXRndHY1MFQ1aDZyTXAyNFNlK1FqYUhU?= =?utf-8?B?UURRN21ZbEVZdUkxSWFaNDluNFh4QnlFZWl5bnJzMGVvdVNWeDg2VFh5eGtI?= =?utf-8?B?a1ZkM1J6R0hGNjMrQ0VyYVRvdlYrSnpIU2NoQmNEeFRjT1g1WXRkWER4NXhM?= =?utf-8?B?dGRvcE5MaUwzTjNoNnFXOUVQUGxQWDAzS1ZRZFFGZ3dCOHVraVdLZ0JuSmJQ?= =?utf-8?B?TmtnR2xLUGhXMkd1dzdhNVIzWTFDbFQ1L1ZUNlJjdXlvYWsvK3Q1dUhRcWJY?= =?utf-8?B?dmdva2tjZnFuelZTd09Qb3pNbkxYNHVLQXNla3lVd2U4TGRrL1lHM1lka0g4?= =?utf-8?B?aWZUQ3FUd1VnU1lGN01ZNnhZY1JNRFIwSklzUldBNytncm94WWVLMnlJNGha?= =?utf-8?Q?rLm6rekZFKBfr/th6wezRXPqa?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: Cc9Ftpk1iReHwA1zCWBWKl6CGSpI3BV6O/MSD7JGA4G4wvLs1KDeUiZ9u2aQZ0p2OKTVoMQuzxxHjdAxeoNS2MNyfWdU+CGZGYQ7pYMa5VVkjN+zOWKtH0sGiNur7NpzpJtIMU+l4NxNkqkKxXuGzL6ziM9CHMbwyA0z3AXZr7viFwmbaaA9qKPzLk5VHW2NkWrqDKOR3XhF6QSz3is3CknQ5rnmrsNAklvMWhrP1cZK0h4F/bE3HPun7n2iYP9rUt5BxS2MBA6CN4i6GUX8w/d6XWyD3P4yySW/3zh/LthX9qbHU4TfJ5f0ftTAgP3SwlDMfYFeT30GW7F9Kp9nEUUKM1oC3Emc5ca9C+UUrsAA4kU0aY41/crDWXWsiXo8NV3rK9W4naRXzYeQMknWD0sOfDWGrZSR73tLyADvOkPlLX5j3XfzjukbeNrfvA+de4iZqJnUx5V/kWS4fr6GSbF57dRFrmE/BA1XCj+X+DsbUSyeCadK00dAjrTGSUO88Z8GOQHAnMZn0CDDbtoPsbhd3rzanpaXrOh4bkQgBxDzEhxIMVMlhT8L3sGJNg+Y544VYwSBfnf7LjGc+MGmT4VC+4dkcF6/qEUxPZzEw01t2yc/+kR5ngzp6l59kGuuK3+YbF13mHcA2xCoDP/B9nki7AJf/b487R9y5OqL52kYKT1AKA5V/irOkSwUT5lv0kUS3giTC4N75HwzXKqJ6W/l7dqJF2JJh1qz7vOmo3aX3NASZQTVldH5Ie3vzA0cRnfVOlRiSYAeFg/dMXiAlOQKXhQVaXB9Qru7xnLcrg0= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: a0cedf43-bc20-4db7-1371-08daf4dbd83e X-MS-Exchange-CrossTenant-AuthSource: MWHPR1001MB2158.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2023 20:30:29.0402 (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: b2RqTiysciNsMLAYCPeA+Mqn6MKCb8q0bu9kKB3dIuZB4fE8K2B9bVLCxnj3Aqj/yMkd1lSu0KI6boYVWRPYsA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR10MB6809 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2023-01-12_12,2023-01-12_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 mlxscore=0 spamscore=0 bulkscore=0 adultscore=0 suspectscore=0 malwarescore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2301120146 X-Proofpoint-GUID: TsDcIANsM7CG3ONm2uO-MmiqNqaCvxaz X-Proofpoint-ORIG-GUID: TsDcIANsM7CG3ONm2uO-MmiqNqaCvxaz Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org Hello, This email is to initiate discussion/collaboration on adding a new user-space program unwinder in the kernel, an unwinder which uses the SFrame format. What is SFrame format? SFrame is the Simple Frame format. It represents the minimal necessary information needed for backtracing - i.e. Canonical Frame Address (CFA), Frame Pointer (FP), and Return Address (RA). SFrame unwind information is available in a section called .sframe, which is itself presented in a new segment of its own, PT_GNU_SFRAME. SFrame format is supported for AMD64 and AARCH64 (be/le) ABIs only. How can I experiment with the SFrame format support? The support for SFrame format is available in binutils trunk. GNU assembler when passed a --gsframe command line option, generates the .sframe section. The GNU assembler uses the .cfi_* asm directives emitted by the compiler to generate an .sframe section. GNU ld merges the input .sframe sections as necessary, no explicit command line option is needed. There is support in objdump/readelf as well, pass a --sframe option to dump the .sframe section in textual format. Where can I find details about the format? More details are available in the include/sframe.h in binutils repo (https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=include/sframe.h). SFrame spec is also present in the binutils trunk. Some more content should be available online in the form of GNU Cauldron and LPC 2022 presentations: this was talked about under the name "CTF Frame", but has since been renamed to "SFrame". Why is SFrame based unwinder useful? Having an unwinder for user-space programs based on SFrame format can be useful: - enabling -fno-omit-frame-pointers has performance implications and other issues. - Compared to .eh_frame info, SFrame is a simpler format to decode and generate backtraces. SFrame unwinder itself, hence, is small and simple (https://github.com/oracle/binutils-gdb/blob/oracle/sframe-unwinder/libsframe/sframe-backtrace.c is how an SFrame based unwinder can look like. This code uses libsframe APIs like sframe_decode, sframe_find_fre, sframe_fre_get_fp_offset etc. to generate backtraces.). There was some interest, at LPC 2022, in exploring an SFrame-based userspace unwinder for the kernel. To get started on that, some discussion on following items will be great. (Please feel free to add/delete/correct any items; my knowledge about the kernel and its internals remains limited). Userspace unwinder selection ---------------------------- IIUC, userspace unwinding is always frame-pointer based in the kernel. This is unlike kernel-space unwinding where there are a set of unwinders to chose from: say, for x86_64, UNWINDER_ORC / UNWINDER_FRAME_POINTER / UNWINDER_GUESS. Additionally, for kernel stack unwinding, there is also a framework in place to plug-and-play these different unwinders. For userspace stack unwinding, first, we may want to add new config options, such that: - USERSPACE_UNWINDER_SFRAME => This option enables the SFrame unwinder for unwinding user stack traces as the first choice. User programs must be built with SFrame support. If not, no SFrame section will be present in the user program binary; In such a case, the userspace unwinder defaults to frame pointer unwinding. - USERSPACE_UNWINDER_FRAME_POINTER => userspace unwinding does frame pointer based unwinding only. User programs must be built with frame pointer preservation build flags to ensure useful stack traces. Second, regarding "the framework" needed for non-frame-pointer-based unwinders, more thought is needed. Interface of the userspace unwinder ----------------------------------- * OPTION 1 This one might be overly simplified but is an option. We add the following stub: ... if (check_sframe_state_p (current)) // checks for SFrame sections if CONFIG_USER_UNWINDER_SFRAME is true sframe_callchain_user (entry, regs); // current is implicit, stores callchain entries as it unwinds using .sframe sections ... in the following target APIs in x86_64 and aarch64 to give the desired effect of "userspace unwinder selection" -- perf_callchain_user in arch/x86/events/core.c -- perf_callchain_user in in arch/arm64/kernel/perf_callchain.c where the functions look like: static inline bool check_sframe_state_p(struct task_struct *task); void sframe_callchain_user(struct perf_callchain_entry_ctx *entry, struct pt_regs *regs); Here, sframe_callchain_user () will, first, perform an operation similar to dl_iterate_phdr, because we need the location of the SFrame sections for unwinding. This means, for every sframe_unwind() call, we go over the memory mappings of "current" task_struct and find the locations of the .sframe sections of the program + its DSOs from pages that contain the ELF program headers. Next, using these SFrame sections, it will then decode the SFrame section and unwind. * OPTION 2 A possible optimization is to instead: 1. Cache some sframe related state, "struct *sframe_state", in the "struct task_struct" (guarded by CONFIG_USER_UNWINDER_SFRAME), and 2. Use an API like so "void sframe_callchain_user(struct *sframe_state, struct perf_callchain_entry_ctx *entry, struct pt_regs *regs)" This state (struct sframe_state) is simply put: data about the size and addr of the text and SFrame segments of the program and its DSOs. Ideally this state can be setup at task setup time and needs to be updated only if there is any change in the DSOs (added or removed) [1]. The size of the struct sframe_state itself is small here, as SFrame sections can be decoded on-the-fly with no need for additional mallocs. [1] PS: That this detection of "add/delete of DSOs in a user program" is possible in some efficient way in the kernel remains an assumption; I still need to figure things out. Any inputs on this appreciated. Other framework --------------- The kernel stack unwinders adhere to some interface allowing them to be used interchangeably. The requirements of the userspace unwinder are a bit different though: not all user applications may be compiled with SFrame support, which means there needs to be a way we fall back on the frame-pointer based unwinder in the kernel for unwinding user programs. This requirement, however, does not mean that some framework changes shouldn't be done now to make things work better. Any feedback/ideas are appreciated. I have also not been able yet to evaluate what other impacts could this have on perf, if at all. Thanks