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 79E2BC54E94 for ; Tue, 24 Jan 2023 21:58:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232321AbjAXV6r (ORCPT ); Tue, 24 Jan 2023 16:58:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38906 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232680AbjAXV6p (ORCPT ); Tue, 24 Jan 2023 16:58:45 -0500 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A74834A223 for ; Tue, 24 Jan 2023 13:58:41 -0800 (PST) Received: from pps.filterd (m0246629.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 30OKtQIu022125; Tue, 24 Jan 2023 21:58:35 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=message-id : date : subject : from : to : cc : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2022-7-12; bh=fPGEY0BIgxrukbDtMsOUdrhrpn8EEZPWeP5Fryw0HYM=; b=aZ8e2Zw+6ZSxTLmtajHuRxsGpaIvOEyJMv/kGTmAtQJoodfXHqrFJ2yIJM+HvqOSVBkp Ahy+RWZMP2DlYXeAkWQDYdEelhUGnSwAr/YkNv9C6uD5WHtPzHJtQO/7GnFW1Kj8e27t weivuRC2mrnwIoigsuQzQ4TJPp5v6gy+hhgw3Rz0T+CwSSWqsJQQM+LwH/vsDwfr0bN3 iKerVd2dAHLOomNFzbyQF+bWcwxWzucoggdBAJIx4GhhYBa51TkeYE1zaBjK9XI1mC5W wMVju2VRJTPU8X+Tn2dmAUHvypLnsaXhsUqwPTWdO8JHqWRIWMsbsidHCNK79LcGm7ln nw== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3n87xa6j5h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 24 Jan 2023 21:58:35 +0000 Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.5/8.17.1.5) with ESMTP id 30OKTUsi021054; Tue, 24 Jan 2023 21:58:33 GMT Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2177.outbound.protection.outlook.com [104.47.57.177]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3n86gcd3g7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 24 Jan 2023 21:58:33 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q8//aMZEY0NFoq9VkZwFWkdfQjnnx89rbC3KBTxNTt+0IXnxRZAYLLKdHudExhsS27RF/wd7V87GRFB7XkJ6V4QJK5rssOdzFZwyEqgLL/l0qhtewcjUjRHoBhqK2POltdJGu2zH9OQz+fa7NOj0VApLmmw84m7LYA2rZav2yieOU7pNea29waSFc4tj+/BwMVS/uZ9vc+1AraRfi+FtbMmj5U8T0gts9WsJ7pNFLHrnvBcBBy3mO5PAOoxz7SD0fqxqdTv72YmnXW6WQyGWbuk6MKcKII1oP90XD38gtPIrO3M1eCamrdfnFQEpf+wHNGr857QLKglXxMjik9iqQg== 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=fPGEY0BIgxrukbDtMsOUdrhrpn8EEZPWeP5Fryw0HYM=; b=HfkXVAa1FXIJEGYIiSjVmdA1fAh1wlK7sy2AvDORHofxGb+dVBV06zHFr1hf2+1O24P4pHVrarxavp0QtxuaOXvEnBV4na009fggmuTHP1QWDKgSjGT4Qd5VDz9x7F3BnWnJAaLgEgp5tsAEI3OM/vexOPHlFkMV21cNawcfrQ/m6qhZkDsie+GEdghnlg8jWbljbNPFAQ5P1mVFmlMZ/8Cm3wQeEci7+UVRE7B7dN5vnXaMdsw8iRo5kg7C1/60ij0f4zm2hvWi38taylGzc5M++d1U/X6cFmSaDnYDzjEuw8UOWMMW+Xte9SQHBaplM0owpyycJz0YroR2DneLVQ== 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=fPGEY0BIgxrukbDtMsOUdrhrpn8EEZPWeP5Fryw0HYM=; b=MUywECDgHJLQQVUg31WYdhGPDvM7YHvna9NFWD64ZVbdctSvdL/8qRbLMvzGZL9V92snVWlefvAxfy3sbj+c1UZmSnD+f5XeAD6jAwBs2y2o6MEDApOcQn9DNbzfaSQfiEADDaSPI1AQFSliPCO+enVfr6zAzN4JtdhN3s5ui28= Received: from MWHPR1001MB2158.namprd10.prod.outlook.com (2603:10b6:301:2d::17) by PH7PR10MB6355.namprd10.prod.outlook.com (2603:10b6:510:1b6::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6043.17; Tue, 24 Jan 2023 21:58:31 +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.6043.009; Tue, 24 Jan 2023 21:58:31 +0000 Message-ID: Date: Tue, 24 Jan 2023 13:58:27 -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 format 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 , andrii@kernel.org References: <7dcae1d1-b0f5-a497-a473-26a43f1b1ad6@oracle.com> In-Reply-To: <7dcae1d1-b0f5-a497-a473-26a43f1b1ad6@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MW4P222CA0017.NAMP222.PROD.OUTLOOK.COM (2603:10b6:303:114::22) To MWHPR1001MB2158.namprd10.prod.outlook.com (2603:10b6:301:2d::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWHPR1001MB2158:EE_|PH7PR10MB6355:EE_ X-MS-Office365-Filtering-Correlation-Id: 6d14a1f6-78d8-4339-6e07-08dafe562161 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: QBQCYK7Ha9+MLChNVcsSX1mgR9IEaC5ZijmGLWzihR1pmnS1GuPy75WmbfVQvzjLYV8MK9++7bDHlB06mE4bTFQ7QStT6wbPBFlwY3RWy4cPoTNzTOwPKzgfBD5SFi8i+NJVb2QW1TXZyb/udic5tvjYDXgyre077db5knV7qoybEtVOZ98XsrgwVgxoOjwsjAuoZDJ7hbql+ILz+nQPX4LNqOdvxSuQM1vhP/Rb6xueUcG26UTiV7/6WQT5irQE2ojr24exNjKN8n7UWfFxtTvtwcg9NTfAT7UkQ4t1n86jxyNbBVKoY94R40kWfPUyYUHV5/0AWHazNwa+svgaqWjZ37hPJuCtJo8xJF0Z7TrZImtv0xH9dck5LvgTdFDyNqmHT2xkKvgxqxpxzF+Y0kpzXCQZGjmI0R9T3ix+Ji6pIs5YDsNu7FhDnyL940TM2RaZAgbCWgtM5myJ74cerfoR+t5iT2afdDhFZbnQoS1+SWbWqRsBsmy7gAaITw2h6P1fCMeWZgrtLvvEKXd7s40AImHR74qXXX3Ymf7HAvTbAu0GnAk04eu2vkTrIJrrJv88+P1zYLc13ugTKFnkDaBBKjpPlw7MNvvlgiMl0pi6zJ/MYJI/IaJ7sE6H0soXFiRpDH/nH7iHgtwASAvksfg3M4NiNFwrkGAAj2HfeAkSCtAerwzkrw0/lvRIYQDVo4LfkW8TwPQnThUPVJqkALrYHWVNnNFoTd6krow3xA5bybvvj33N/3ZHxaMi+r7XOzUIqol9taQlbavbRZDdR/DVFNTGzx3xyo8VcNYTcgqpUugmOMLU6BBK/b4XETjk 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)(346002)(376002)(366004)(39860400002)(396003)(136003)(451199018)(31696002)(83380400001)(6512007)(53546011)(2616005)(6486002)(478600001)(31686004)(966005)(54906003)(6506007)(316002)(6666004)(36756003)(41300700001)(6916009)(66946007)(2906002)(66556008)(8676002)(44832011)(38100700002)(8936002)(86362001)(26005)(186003)(4326008)(5660300002)(66476007)(66899018)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?d1FFTjN2bldWRFhUOHRmY01qN3ZrZXBaOG9YSFNocHdPQ0pVcGVsVW9UTGlM?= =?utf-8?B?a3VwVlgvemRyZWNZL1Z1bXRRbVNsQW5vMStkU0hnWVY1blFSUEgzUkxQM21G?= =?utf-8?B?TFg5eW5vN3ZwckZzZS9rRUxuTG96T21Hc0xZNXZyUyttTVl0OWxmOTlRR0Er?= =?utf-8?B?Um9IRjlNMlVaK3Q0Z1lRYnRJQWNwcHJ3OWJvbFJYeUFmK25xVzROeEZEc1BQ?= =?utf-8?B?RVREK0FTdVo5WVhzbzFKejVkbnEwSDBTUTRQUlkzR2huL2JKdGJESzdLRTRw?= =?utf-8?B?dkplVVJVU09xRUpsbXFGTTlmSkRIT3pHZU80M2hYMkFST25NRDdXZ1cvcmVI?= =?utf-8?B?RFB3WG1yejl2aTRTV0UzZUs3blRWaHd0UFk3ak84VzNhVE1zblpoVytLWXlD?= =?utf-8?B?d1JLaDBsekR1UG5pMFBKK2JPd3hWaytrN1pVRlYwT3laOTBUY2pLYTJRR3VC?= =?utf-8?B?YnFlSG9XNERSSzczTzlOcG94QUtXSHpiWFo5TzlYcXNyK0ZKNVo0RzVEd2Ez?= =?utf-8?B?R01XYzNObHVicXhCSmRFS3VBaERtWmhKODd6c0hHOXBTZ1dWZFZybCs3dzZC?= =?utf-8?B?bEdYdE5CbTNSbDJnTFFYZnc0TjZQYU80YnBxZjFTODJMNXYzbUM5dU16L1dn?= =?utf-8?B?WW5sTnBsdDh3YkdDdis0VlBNK1c5L0N5azJhRUYyME5MQXZIUkFZeVN1ZVpv?= =?utf-8?B?RDZqVzBubE43K3UvK2g0WTlIclBvSURPb09ieENvekduMmJmMkhzM2ViWlY4?= =?utf-8?B?di91MFUwZlNUdEg5dDRuZnV0a1Zna0dIS3RNUEMrWkhiSUlNZktuWWUxZHlp?= =?utf-8?B?dkx3Q0hTVmhYV2M1Y1RwL0VoZDNQTVZrbENUODB4YWR0YldUL2RyRHdoRG5Y?= =?utf-8?B?dlBLMGRub2p3RHNxbWlOOGV3M1pWUlNuQm5xa2RjNHdoZkozM3g2cStNVytz?= =?utf-8?B?dGJreCtOWkJYNnBWZUZaaExBQUM4UUJ3elVicm5Ea1I4RFNMb29TQkE5ZTls?= =?utf-8?B?Vmkrb0dJbzlIbUJaQTVtM0d0azc3SzFmMUVmeXAwOTBVWGZZNm5TMU9QNG5x?= =?utf-8?B?Ync2S2R3bXdJenBxa2lBQW5wVnIwOGwvM05BcWQzUWViUkFGcElRMXhYUVNt?= =?utf-8?B?ekorVCtUMXVSY3FSZWVtT1N3eGlZMW1CM0JlY0IvZk45bXF0bGNSeWY5dUZT?= =?utf-8?B?ZjIvM2s3S0xNSzlQL0pKbU5FT2o3MXJkQkdTQlZPT3NiNWRQZi9tamx2TUEx?= =?utf-8?B?YS9hOHd0aUxsOFZoemd3a1dNVnArTUdvWmo3QzVJNXlOK0ZCek4wbll3dER4?= =?utf-8?B?cjliTW84RUJkTlljWXlOV09CV1laUE9RU3BvVGxhTmg3STYydXA4NXhsUTZw?= =?utf-8?B?bkZFeEt1THVhSG9vMDBobjRROUtKUkNIdHN3TG1YQ0gzbnVqbG5palFVMlVB?= =?utf-8?B?N0RMaXFTdFN0T002K2pBQWZTWGRQbWxBclpvcE4xKzdkcjR0NXZjbjVnMDBv?= =?utf-8?B?UHJHNG5JUUZTYWh4SlFWUmd5djc3VmlDZHJzWVNXK1ZZM1htemxYL1MrRGVZ?= =?utf-8?B?bThxejR2VitZYVVBaFZXeC8vNnE3K240Nm9LTzZYcmtIeGNLL1NMZmZyY0Er?= =?utf-8?B?Y0ZodzlObVlxR09maDVGbVI4V2lEdXo0bldGR2tWUFA2cDhQNm50eTdaNjhp?= =?utf-8?B?SE5JcDFJQjRFRTZ5Q3VxM2NmVU02ZDZoN3dTN0Zka3ovcEpNK09ySGdpeDQ3?= =?utf-8?B?cG5BeGNqV1ZvWXNqNmY1ZTRPc09reDRWUG1tYTdnNzJvZUo2dmZVY2pFeGxT?= =?utf-8?B?NDU0KzRXQkE1eExRNFBvbGdnMnBRS3IxMmVpdzM0ekt4L2piQ3RmdTh0ZktQ?= =?utf-8?B?b3dzSzBCUjN3Y25DVjFRQ1NRQituZkF1dnZKcnRuRmlUUDUrQkUxTGZXWDVq?= =?utf-8?B?ZGJDYjVJZGxTcDZGTmRRR1NRemlCSEJqcDIyUktzTWJITldtbE14UzQ2bSts?= =?utf-8?B?SGc5VmNsT3AvWE9RY0RSUi90Y01JVUovbloyWEk5NktJV0M1V2RJSTM1KzFI?= =?utf-8?B?cDEwVWJLTlVjR1l1M1dmUnAxbjlJMTN0U2RhQS90ellmdlgvNHlJaldOUFNp?= =?utf-8?B?blpJbmY3ZUlrR0pudFVON2VZQk4rS3lZNHY2N0MrLy9jNFlpSDAzVkcyR0Iv?= =?utf-8?B?OUE9PQ==?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 1pNwl/ChIra9uxIiiWCWtOfCOhf7Drc3jBQ5Es7+fcibaNfYd1/iqLvOTj1wLxQAsuJQShdjlNHbXG4GNXugCd5SwhO0AJn4U+oyPXybqMMiCO/wDnw8LvGFOP0I6jWO3Zbqwom9XKCPH2teKiFXrMDhrN2eR8nmil9D0fLWf5P/qTEqAnUDbXAKq9MieNNgBAp1lRQl5/Flner5eCIDFjPmmo1zBGC5dfGR9bacHjgfny910dkIT2NfaxARvRfLRIWFFX7p7McHK5OEFD2rWEz089TR5rYv8ZcPPOcEAW8AIMyNIU7PlQIgShPnG4ia5rzODz7GzeAufKvb4j51Aqd4bwPulNPcU8tWyNQdLG9G3kMn0W6wMl3Dovu3fx2Vu82syOUoFCVgTZxYqdycki54CjjJGbhoZLtSBK+OOwsiwknE4jd/eX9uFboEWfzHyjMgq8FnkRYvCFFjNxzZ5IKZ80rc+9V/chSNqmY/40SQ+P/LRE4/kgi3PEGznmFBdRJ9GqQgVRsyaUrgQ6p6NDj0nKJyTOXrYEcc0VQ1HFJmoJ+uk3BPriQnquspYEwf7JggLAaknTZlYxUxd1UJeXhcXwpcwtBpoWzdZOBaIfQTb8hVuYssrWBIiURdwews+rbXTIe0mXR+IhEAYLZHyOLHjbEI32oXOyosU6eMhZn/LYiybfe/qyn6jivakMHLjGrzbGam4E54yYFAXHOKsTQoBz296kSH/5sVQsLtUj347svVS0BECpNt33mp1YID95LWqzjH2m61SPjcXJYNScZ7yp2fx+11Jp2vpSrUxwhfXwDBJgGZPpdutBa8FH70 X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6d14a1f6-78d8-4339-6e07-08dafe562161 X-MS-Exchange-CrossTenant-AuthSource: MWHPR1001MB2158.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jan 2023 21:58:31.1240 (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: 4Hy0SF6WNEXJQQxd9H1CzjVV/zUaQiMZg0Th68oCb9NAw5WHWZtKXSdnEmOCLnXgQB34hpPVQ/KItIXXerA3Fg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR10MB6355 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-01-24_15,2023-01-24_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxscore=0 spamscore=0 bulkscore=0 mlxlogscore=999 malwarescore=0 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2301240203 X-Proofpoint-GUID: Wr9GHjY0_53V7GjoCGDfknpiyER9IjFN X-Proofpoint-ORIG-GUID: Wr9GHjY0_53V7GjoCGDfknpiyER9IjFN Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On 1/12/23 12:30, 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. > > 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". > The SFrame format specification doc made it to the (binutils 2.40) release documentation last week https://sourceware.org/binutils/docs/sframe-spec.html. Adding here in case that helps. > 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