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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A9EBC54E68 for ; Thu, 21 Mar 2024 14:38:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 19A636B0083; Thu, 21 Mar 2024 10:38:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 123446B0085; Thu, 21 Mar 2024 10:38:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EDE876B0088; Thu, 21 Mar 2024 10:38:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id D4F9A6B0083 for ; Thu, 21 Mar 2024 10:38:02 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id AE8D6120C27 for ; Thu, 21 Mar 2024 14:38:02 +0000 (UTC) X-FDA: 81921300804.22.3659837 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.86.151]) by imf26.hostedemail.com (Postfix) with ESMTP id 57562140010 for ; Thu, 21 Mar 2024 14:37:59 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=none; spf=pass (imf26.hostedemail.com: domain of david.laight@aculab.com designates 185.58.86.151 as permitted sender) smtp.mailfrom=david.laight@aculab.com; dmarc=pass (policy=none) header.from=aculab.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711031879; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=njOL/fF4jXAi8Kv6ZaB53dFWeQ2EeFBy8qOefZn+tec=; b=PM6Tgzvm+VekwrPU8m0Ipb/sxud61S6/5J47dm1tgPgDqjRHLcZVXZ3Xr9Vickm6LCFwRp vW9lOO/ksLI58Td+N+0r8JTY+xljY1w1yhLlmGHfDjLVhruRKCxbkebqannkO5qp5L/Kfm DwavuK+Wz56eoL0IkXLKM1QhGUbsagY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711031879; a=rsa-sha256; cv=none; b=DZeLiF6xdW8y0gVQBLo9NIiJT/nnsDa7zYN0jfQOPzsmOO9+xG8oKFA3STeFPjAocg3xYN KHEei7G41BMbXnUNMPg/eiyKPyZEFe88FPeDck4kB7vCGsqRE01xQqAT6dwsuHz2yC1f+l QVYTKaiZLLyvUBcYQ/OJ2ugzGNftKzI= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=none; spf=pass (imf26.hostedemail.com: domain of david.laight@aculab.com designates 185.58.86.151 as permitted sender) smtp.mailfrom=david.laight@aculab.com; dmarc=pass (policy=none) header.from=aculab.com Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with both STARTTLS and AUTH (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-187-6fRfpWVCPDm3cO9Kixse_g-1; Thu, 21 Mar 2024 14:37:54 +0000 X-MC-Unique: 6fRfpWVCPDm3cO9Kixse_g-1 Received: from AcuMS.Aculab.com (10.202.163.6) by AcuMS.aculab.com (10.202.163.6) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Thu, 21 Mar 2024 14:37:28 +0000 Received: from AcuMS.Aculab.com ([::1]) by AcuMS.aculab.com ([::1]) with mapi id 15.00.1497.048; Thu, 21 Mar 2024 14:37:28 +0000 From: David Laight To: 'Russell King' CC: Ard Biesheuvel , 'Jiangfeng Xiao' , "arnd@arndb.de" , "keescook@chromium.org" , "haibo.li@mediatek.com" , "angelogioacchino.delregno@collabora.com" , "amergnat@baylibre.com" , "akpm@linux-foundation.org" , "dave.hansen@linux.intel.com" , "douzhaolei@huawei.com" , "gustavoars@kernel.org" , "jpoimboe@kernel.org" , "kepler.chenxin@huawei.com" , "kirill.shutemov@linux.intel.com" , "linux-hardening@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "linux-arm-kernel@lists.infradead.org" , "nixiaoming@huawei.com" , "peterz@infradead.org" , "wangbing6@huawei.com" , "wangfangpeng1@huawei.com" , "jannh@google.com" , "willy@infradead.org" Subject: RE: [PATCH v2] ARM: unwind: improve unwinders for noreturn case Thread-Topic: [PATCH v2] ARM: unwind: improve unwinders for noreturn case Thread-Index: AQHae3ROEuI+AaCprEesIWGaAOB7ebFB9uHAgAAWtoCAAAVW8IAACy4AgAADrmCAAAjqAIAAC+ng Date: Thu, 21 Mar 2024 14:37:28 +0000 Message-ID: <9d6057b110034c04b6b590522c8c69cc@AcuMS.aculab.com> References: <1710906278-23851-1-git-send-email-xiaojiangfeng@huawei.com> <84a57ca8-8963-ca24-8bd1-ddc5c33bf4da@huawei.com> <0fd55e156195440bb1d815dd8300894b@AcuMS.aculab.com> In-Reply-To: Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 57562140010 X-Rspam-User: X-Stat-Signature: nisqbd4oamabusmfb4b6peignoqykp5f X-Rspamd-Server: rspam03 X-HE-Tag: 1711031879-208010 X-HE-Meta: U2FsdGVkX1/GJb1ApwoNlZCAyd/72ZzSME0pwQwfNRjXo5iS+zX52RjMZQG4aDx44JTVHrQDOjk4fSvbsw9vNPxQb1blX6XuydoSJpSKug+0ZdgSAzzdIjEwHLXzkr2ml3YGTT7L6Yd4E/f/vUzsYre1i3GhNprsRwIWhLHiUctit3dviOBGuG5Im/X73FwubyFD9LUQmZgjvNvEVIVRMTGgnc+jYA2w5P+rcdyHtEDWD8gqteD3sa7mMGE76SCDVGWCf2zoTz5skLBH0uY49V5Rpzw9GetcngUV3+Nga/DUS66VrlTsHmw91CT2BqQlAx8JGt3sYyVJop+Tk0zKGua5iw6POr6mR67IHLQZTbRobSvEU87Cyk+RyJhcXr5cvsL4RJO3uJoGMYl+zNIkkmqrzVnDifZnm57Tt+6sS1wWTsnYS3yNpHxSU+5kv5rd/wQzP+wSf6xOBWj1HbPioRjYi44/p8tH766269DqeFwNHcJH+4GRNjx+Pn2mIRKkn2mgRpDNCBKAGL/fBPeKWb2V/jGkjR+Z9voSH9uBYFgkMvm4/QC+UKAGnV9jepw8UC1vUhnYTIVp474Rbb5uR93D8zYNCM7vOkU2pkdOQlIAvxdEoEZIeiFTlAHIIdTelyNzNjNVki47sHYDalN904HaYwyQJE6Qh/mZYpE7ZESG9AeXpkYEWpU+CADxTh2s3CJ9UoWr8pZ5rGwimzQIjQLvr3sriNng1l86wpKsKLbHhd5ZLXHG2qY45LwX9XvSv7RrKnvVhZmS0vqESzN06gm3AYJ+ZGB16PNbCY1P0m0vlAbg4Wt59UAOyI7gixUh8LzbrzdUcfTAUKNyf40Cbb7jNew4GdIUFHU3nRzry2O7n4qVsUuVMkzIc7/63XYXWl304VENgXdiWrgHhKokyxb49X3onKuPfZ1L/26XQfYLkgqgKdkZreoowkMU6yAjW0Xps5ndCRFCNBXJjHF MZgh7LNj KkvN/ixFq5MzGtOkcoX+1Sd6tBC1zFM1+/mwv0etdHN2d7ucIpk/uDkYJnwN71scKfqgFXTwCFgVqXCqsrqsuh1JcvqRwLt+8SSF4ywGI0W/pOVzjEbvvaKJpl5gJBrouSGzFenm1GOQkQe3q4VrjZaKZFEBh6OHKssMWyj9aoADPBJxShMUE9d1HJOJxJYkbmlk3ZdOeigPAAl9YWXCLnLf/JF/YAD4PdVAzNqP2vJu5CMDKuwtZTO8U3I/Tc/9U9Gsgki9jkN3NUBbMnAmidy7RiRLiZewmwO0fDA6osgPEg8Q= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: From: Russell King > Sent: 21 March 2024 13:08 >=20 > On Thu, Mar 21, 2024 at 12:57:07PM +0000, David Laight wrote: > > From: Russell King > > > Sent: 21 March 2024 12:23 > > ... > > > > That might mean you can get the BL in the middle of a function > > > > but where the following instruction is for the 'no stack frame' > > > > side of the branch. > > > > That is very likely to break any stack offset calculations. > > > > > > No it can't. At any one point in the function, the stack has to be in > > > a well defined state, so that access to local variables can work, and > > > also the stack can be correctly unwound. If there exists a point in > > > the function body which can be reached where the stack could be in tw= o > > > different states, then the stack can't be restored to the parent > > > context. > > > > Actually you can get there with a function that has a lot of args. > > So you can have: > > =09if (...) { > > =09=09push x > > =09=09bl func > > =09=09add %sp, #8 > > =09} > > =09code; > > which is fine. >=20 > No you can't.... and that isn't even Arm code. Arm doesn't use %sp. > Moreover, that "bl" will stomp over the link register, meaning this > function can not return. With 9+ arguments they spill to see https://godbolt.org/z/Yj3ovd8bY Where the compiler generates: f9: cmp w0, 0 ble .L2 sub sp, sp, #32 mov w7, w0 mov w6, w0 mov w5, w0 mov w4, w0 mov w3, w0 stp x29, x30, [sp, 16] add x29, sp, 16 mov w2, w0 mov w1, w0 str w0, [sp] bl f .L2: ret A traceback from inside f() definitely needs to use LR-4 for the stack offset. (arm64 doesn't seem to support -mno-sched-prolog). I've failed to get different sized stack frames for the true/false sides of the branch. The compiler seems to pre-allocate the space for extra args rather than using 'push' type instructions. This was certainly better for some x86 cpu (p-pro?) but has now gone out of fashion. =09David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales)