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 B4C7AC636CD for ; Tue, 7 Feb 2023 08:37:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229924AbjBGIhM (ORCPT ); Tue, 7 Feb 2023 03:37:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59420 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230460AbjBGIhL (ORCPT ); Tue, 7 Feb 2023 03:37:11 -0500 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 037C9303CF for ; Tue, 7 Feb 2023 00:37:08 -0800 (PST) Received: from pps.filterd (m0246617.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3177oDtm019567; Tue, 7 Feb 2023 08:37:03 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=lnyg3ARKXwhT19HRTb8kOP/qRY8/i/2VU0lBrqYU/0Q=; b=l3kqc7lS7I/3UZNRPX6Y0VKZ9Rr4yWzwe4JRTRIO3WZCLDBNG4Mk1x6wBlfLEU/60Xyu t7GaURFZHTJE/hgXboTee1aEcuYS1HE1Z22yjHZtCNyMgkBikE40t+srC9LzHGAcRjJn 9bkj8xqlgU7XUu7E4289oPk0o39LQb2DuwFSC5XnY9APsjGcU3eVHogsAM0+uO6QBajz d+vJ0tv9fgtej1BhC/WswGN4OIBMHveg2eOrx1COIOCtlD86N0mB+CWytYkRotmqA9/X ifjZNOMdlIN680+1NuGkHXaDOBEqgFTWA7cIT5P73o5hb1uKAY6YfAr2h028ZbJee+iC gw== Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta03.appoci.oracle.com [138.1.37.129]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3nhfwu4tk7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 07 Feb 2023 08:37:02 +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 3177t2jc011596; Tue, 7 Feb 2023 08:37:02 GMT Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2041.outbound.protection.outlook.com [104.47.66.41]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 3nhdt5sjy8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 07 Feb 2023 08:37:01 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WIRSh2uOr4IZkuo1dsIa1v4taQxjLM8YCOWhz8ukJk4pcDh3AE/PC3h94PO+yGMXsGvMcLDMcEEcvjc/EQgpUMuWUn1Fmdrf7avr243eZx44aWjT8rupkFRouiCgKUwmVBmlJZOOPq1otVljyMP2RKKtFS/cL2S4lrpCOlWd8DuOihhufJMFEFtPzjQh+uMWjQV+DRRxpNermS3Xg6E6cWD+ZX5FOUoj4EhH+fBFabK+BHQFLDr3ZwepWaL4T3ckHDLyYBX70sPj63XcZkFSTnNK/UURRLM60e71RHRafWeOmX0cJ5Y6iP5SA0EGorXjpDFSjBclcsEp/tUHv1NOJQ== 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=lnyg3ARKXwhT19HRTb8kOP/qRY8/i/2VU0lBrqYU/0Q=; b=ehh3RAZ2ATb4XAQ6X0Vn8K2LNnic2tc/yrKNHwSb9m1jjY7mtHSD27/ePHLv4sa5FeS0V7c7RXvagx+8ZU2GywkH7LApHlS5/3Dk7MfnTFSoECV/Vxv5wuPrUawkODdv7jef4+CHDNhcYvNTcXGpp1HJ5l59Ajw2PsWXyHLPxkHFdentkCGZkvahIrZImVPote0W1BrniZD5C/3oJAG1B2rBy6kF9uHY4srDtcDefMQI3RnW0yVHuBhlcs1OOFJ9VsABcqalm5yOHWKn/YjsTvbFAZe+dmOOqG8oxVTgyu9IVf6+qtHhzpc4Olxhqo7I3UeWowNfDUyD1ZFSsdpOhQ== 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=lnyg3ARKXwhT19HRTb8kOP/qRY8/i/2VU0lBrqYU/0Q=; b=L+OtZQQZCdBlv+Bf/lt1NNx9oo8J5W+FP7VJkR7o7OByOopUcYzcI+877S0KT7/tP9IEwt5Csv9ErXRhKU/s3HnBz5UDvan99BNtdFQOZtComcBGxCTJnz9CGpGqjJGrvv7OwZLhWM7F/5xeTLlvG/UdT1k/xJJPgdQ6/c7pq4M= Received: from MWHPR1001MB2158.namprd10.prod.outlook.com (2603:10b6:301:2d::17) by CY8PR10MB7217.namprd10.prod.outlook.com (2603:10b6:930:71::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.11; Tue, 7 Feb 2023 08:37:00 +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.6086.016; Tue, 7 Feb 2023 08:36:59 +0000 Message-ID: Date: Tue, 7 Feb 2023 00:36:57 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: Unwinding user-space programs in the kernel using SFrame fo Content-Language: en-US To: Steven Rostedt Cc: linux-toolchains@vger.kernel.org, "Jose E. Marchesi" , Daan De Meyer , Kris Van Hees , Elena Zannoni , Ross Zwisler , andrii@kernel.org References: <7dcae1d1-b0f5-a497-a473-26a43f1b1ad6@oracle.com> <20230206144444.01862598@rorschach.local.home> From: Indu Bhagat In-Reply-To: <20230206144444.01862598@rorschach.local.home> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MW3PR06CA0019.namprd06.prod.outlook.com (2603:10b6:303:2a::24) To MWHPR1001MB2158.namprd10.prod.outlook.com (2603:10b6:301:2d::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWHPR1001MB2158:EE_|CY8PR10MB7217:EE_ X-MS-Office365-Filtering-Correlation-Id: fdf2addf-5c63-4921-ed87-08db08e67a81 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 5S2gbMEBeljc6xcho/10SzNwP787u9Fzgi/e96H6u5pdvtsP9h6Y07qVXnmf95j6Yw/TnxrgZVlV2PgFfxzXzd9T531AMLXzgzeMVOLfg2bfFt16wOZ7pQHT7VxgNWgvf0vRNSCkEdmYQfhxukNbYkWNd6xE4YO4d+NJcdWSVAYaizYcbodsSGPbvNXB42GFxwMlz2mZcE6R7q0/N9ARL5NL/kY/CzkOqPx/ZDyMGR4k1feBiXtMXnZnystXWtOhNs8bZhx0MZeaiVV0rXK/Tbu1UUfEWPZPXg3+fCBfvG5SUXI1+WCci/lP3EsdWITHqeCk6bxWKT7QD80H8WyLFl/GCC54DzIWuRks3Avu3syOhFcP9WKtA9wRIMdV5rJAbEkp7DF9S1n+UXLPOeDLn/4+HYi3qakoIeQ0P06xzdyMjAf8ME56lyH4lb7jvHO2v3kpyY4FXcI8PFWgMV3igZwEH3t3AQDkXrMLqQ9kJqATi+TzmORAbLj7Lvh5qkNtiz7cNieEcVsGEM0n6QCLMdNVOXlncKCNb6nCMCRWT2v5DPZhkPSwFxW0Mx4c6DDD4DZ/rvNRaFU8vpi4LXl0GwV0AsHR2+L3i1WNPp6WtlRbJSXDD9T91M5ydT8BFkBxGzTEIKPBUmii+CTqoUHTW157iDoWpnaQ1kL1gj22b77iGvHGem3XIvF+LwiyleDg0DjpO7PIbO2OFn4RzxRYXcSohh0WZWPBoGccbM8bdlixW42lws4qtn8bvpvAkJx4iXKtQ/JmiJYwz8fNFktXoaKGajWi4lNn+TACg5mA7jqkLqUSP+QJ5fF6RRlniVAc 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:(13230025)(39860400002)(396003)(376002)(366004)(346002)(136003)(451199018)(4326008)(5660300002)(41300700001)(478600001)(66899018)(66556008)(66476007)(66946007)(6916009)(2906002)(44832011)(8676002)(316002)(966005)(6486002)(54906003)(6506007)(53546011)(6512007)(26005)(186003)(2616005)(31686004)(8936002)(31696002)(38100700002)(36756003)(83380400001)(86362001)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?alRvanNXVFUxN2U1MWlYVkxJQzN6Tk1XcmEzcmdmM3BLNDJPVHdacTI1eS9w?= =?utf-8?B?djB3ZElKa0EvUnV0a1VjNmxmMUdWUW5YeHliZmxHclcrQVNkK0lqTnM5TGln?= =?utf-8?B?WjdCejJ6SkVKVHRqdEtGbktOdk1UNnpJdzJTNEZFOTg2allzTWVmUUdhV1Na?= =?utf-8?B?ek9ZSzNIOUdqSWNFZzRMRElSUGplVDZhZ0FVc1R2K0FtSUU5WkxsNmFaQTdm?= =?utf-8?B?amFsUmNpSWMvbWxOZHhDNWdZVlJHM0NLYkV5MldXSzRNdmJ0QzBRTFVZWlQx?= =?utf-8?B?QnRxOTBXckZLYXBybGp1ZW1kL2pDSWxhWWdzQjJlTlRKVndyaUVkWXZIVzd4?= =?utf-8?B?VklLb2FBZHg2N2taY1dVS3hSanl3WERPcGFrTnY4UnFWUFNPTXU1RmppQWYz?= =?utf-8?B?cXVidkdoNWZ0Mm1nL3RZN3l3OG5leXByZE9NaFJUUFQ3cE9tRDhtZVZRbER2?= =?utf-8?B?b29PR1NxWjdrT3pJN0t1dGhZL3FNQjhUTXA0Qkttd1ZrVjVvKzVhT0NLU1JH?= =?utf-8?B?ZW5HVkdPQkhBNll5R2t4SkdpQ2NlRDFHemc1OEoxZlpwcjI3blVrQVpXVUpo?= =?utf-8?B?czRqVUc5NGxKeWU0M1d6UEhZQXR6Yyt3aitZVE1qR2MwVGNwTVZVRVRqU3l0?= =?utf-8?B?VCtNMHR1eGkxUTZQRHBHSjUyUDU3L3BrdmpleGF1bE1Pb3RhY2g0TVF3SVpt?= =?utf-8?B?dGtPQWk0YmtzdVJGVEFQZ0RUMkx1T2E2dE1GZUd6ZUVBc0p2bFRPZSt5ajNn?= =?utf-8?B?Z0NLcmdnN0pBNGRqek5JRzUycVNRRGM0d3V4VWhDYUpGbHBYc2dvVXNlVGJJ?= =?utf-8?B?R2tKUW5sVGFxb29URWYvRmFPSzJxMEhGT1pkS0JqeXJXOUF4RFY4NDlFdk1H?= =?utf-8?B?bk9QdStJa2pRTTQvUXg0WDBkaDFHNFBDQWZCV3hnbkw0bU1JR2x5ajh5RzAv?= =?utf-8?B?QjZCUEhFR2p4bW5LemJiaEtpV2lwTzNMTXowZ3VVVjllRXA5aFl2ajlLbE0w?= =?utf-8?B?M3JWUkdCcXA1WlRmVUdQYnhiRTNZb25tNUNpK012VVZ1Z2pZUkFUVFYxTnpU?= =?utf-8?B?eDZ4WHlZc2pKWkVnTU9iQ25KTFlaY2xOWkVsRDlXYi9rb1BJVmNnNEpvN2hk?= =?utf-8?B?dEc3NElQUTMrb0dNWjRWZUVkcHpQVkZpRGRNTGVhWEh1RGR2b3BNa0NvdzdX?= =?utf-8?B?bURiVDJwQnVrRTV5Y3RVWWJqU3cvdDJNbHdoRXpvbUJwWUlxT0ZMbituNFpD?= =?utf-8?B?WVcrN0paK25GaUVyNFpMWWxSVUpJSnBrcFhDeERQdDlWbWJMNnZuTmp5aWNF?= =?utf-8?B?K3BranRQOERYVUxpZGxSTHNHUEl0TUNIUWVtOW5uN1hNaDc1aC9DUmprOTI5?= =?utf-8?B?QU95SmJoTFpGM2R2RGEzWDlaRStuMmluVlJHUXJPbXZSclUzWXhwSTVjS05E?= =?utf-8?B?ZVVPTDgrTDFDclZ6alFFZjdobXlGYzErOWtLMFF0MVlOUS9ub2hVS1pyVTNT?= =?utf-8?B?d3hJOG83STRKUktESVpqZ0d4dVJIL05wRjZ3aFBkNkN1Yk0velZVK1lyWTlk?= =?utf-8?B?U0YzYU5TeUx4NWhyazRTMU1Jcm5Rdmo1OTkvVXdKSkZ4NHBLcUtkdmJhbUZN?= =?utf-8?B?bkVtSUxWZWNMSjZOU01VMnNmTEdJN3gxTjYxTXgra1pKWURYZzRWQ1R4Unc0?= =?utf-8?B?b1dlalo2RGpvbVZFbWFiUHEzdTJpSXVsTTZSSWFBVFhQQ1BmRVRDV1RzRjRo?= =?utf-8?B?OWhvOGdvMVpmQTk0cUtoVm9rWm1oa1dJNldZZEx4UytiR0x1a1lSMldBdUhx?= =?utf-8?B?Y2YvMnBFOUg3TDhGYU4vWGRxWTk1OVBGMEJ0M3FZM09FZVNTcXBtRHJEZHBm?= =?utf-8?B?MHRIY21pMzh1ZGZkN3UvdFdpUU9COWJUNXRPdGlWUEZSQTgwK0VibHg0TElv?= =?utf-8?B?MSt4enN3MW8vMm11ZzRyZ3lJcWoyb29DdG4vKzRocnZKN0QwOVoyT1A2WDFq?= =?utf-8?B?TzhsS0FvZkF6ZW4rWU5BdURVQnp2ZTJyNmlBMVN1NWExSFU5KzB4dWFDck5Q?= =?utf-8?B?Zkx4VUZlbDNwRm1hK09VcktIY2toa3RKRDB3SGhkR1NSQ2d5NUNMQnN5aC91?= =?utf-8?B?eDgraXJvQ2NvbTEwSE0yTEJmUnBBKzRkYXhvaUlmZUtpL0xVKzZINUV0bzNM?= =?utf-8?B?VEE9PQ==?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: YnUxfOJV2ZcfuqZJ69qwb61pFpgdmqyC88CG+j0Y47MVIsNhCYcNa7klFa1bxwwC9bNolv4vq12f2oNnF0/rqpVhL9gRrJ/I/UrTjRm30/93SXSwwSdsYIH+hNgkRRxJ3tZ6nz/C07RjXKMHGGQTWeimPyEGddS4R0oOmA5VEp/zIgDR4RxWivgf1rqTKvWhK45vy9ckXMouT/jyDtE8s5gbvt61/9GUSpQadSG2S7k+Jrxl5v6dflj1nIkJKmPMo+XB5UQ/DDhdrPiY7iOb+OtdlrZprOpukAnzKf5f7ndIHXEt2XZXsACtNk7BoGXUvIs1s37w4+ea6vL78Nu8ilSms6zg4rRrMK88MkkCiuZR957dkq1NH6Sg48Hbxei72SN+S9SV608neh5BP8AlpeJX5k6KJk4ZUfIxlPO5QW8YBU3+1U2K6QqDJ5gF4m7RWEGfySFgg9Acw19UiQRsyJ8R8PIbJlSHTiaUSj/U7T3tJDjRbK7Kk4lJ9Mgd3N0UOFkqIO5Km7OMNPoJ0PokpLzlVtRb8xV4RZCWzGK5WIxUmpL9d+GZ+hD3BNgnr2FoaQFHUkECcpt4UWMX4oym08QEYDTNtjM+RG9g7Qud4txfbeqG6j4FaouGbM4NEfDlmJ4o9G4/hbkbkey5wLrdEQsHGIoJqk+8OE6YVjK87Ms/4Yiad3pf93yYieRFSSgy3mFiyAhxHa0i6PPkNM7jVEtBfrXjdKf4+B6FwqszHUjRROfWX3x3YNE6l11vEQFEfywzwmZVsVj1Rdyefos0Po01c8+r0X+UBwVTJSJSZFJTONBOtctdSK6XZhGknr0qfYqnbGOwVjZv+XVj3awo29LT9fcyDGBsMP8JpwA5pd55zbd/CuhoU5/0aOx0Af6U X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: fdf2addf-5c63-4921-ed87-08db08e67a81 X-MS-Exchange-CrossTenant-AuthSource: MWHPR1001MB2158.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Feb 2023 08:36:59.5611 (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: puOoPnfIrapqLfjLNlE28T6jODg7T9ClQOuL8LQT3MzBpWEGPEI3eHiEy8S9jKF+BbxuYS6Eld7jy3DjN1Pp4g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR10MB7217 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.122.1 definitions=2023-02-07_02,2023-02-06_03,2022-06-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 mlxlogscore=999 adultscore=0 phishscore=0 mlxscore=0 malwarescore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302070077 X-Proofpoint-GUID: xAB7zGdmMP4C2yjznedbKDrFcfyrZYD6 X-Proofpoint-ORIG-GUID: xAB7zGdmMP4C2yjznedbKDrFcfyrZYD6 Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On 2/6/23 11:44, Steven Rostedt wrote: > On Thu, 12 Jan 2023 12:30:26 -0800 > Indu Bhagat wrote: > >> 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. > > This is just an FYI that I was looking to have this done too in a > generic manner that perf, ftrace and BPF could use it (and anyone else). > > I sent a proposal about it to LSF/MM/BPF summit: > > https://lore.kernel.org/all/20230206103828.6efcb28f@rorschach.local.home/ > > -- Steve > This is great! FWIW, I've been attempting to get a _POC_ of some sort for an SFrame-based userspace unwinder in the kernel (along the lines stated below), but it needs more work. One aspect needing attention is the code stubs around accessing userspace SFrame pages for unwinding in the kernel need to be worked out amongst others. And of course, testing ;-). I am excited to see this proposal and can help with SFrame decoder / unwinder when it comes to that, if needed. Binutils 2.40 ships libsframe, but I'm thinking it's better to have malloc-free sframe_decode () API for the kernel usecase. Thanks >> >> 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 >