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 BCE61C54E68 for ; Thu, 21 Mar 2024 15:21:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2EBA66B0085; Thu, 21 Mar 2024 11:21:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 29B2E6B0089; Thu, 21 Mar 2024 11:21:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 13DA56B008A; Thu, 21 Mar 2024 11:21:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0047D6B0085 for ; Thu, 21 Mar 2024 11:21:30 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 8FD3DA1EE5 for ; Thu, 21 Mar 2024 15:21:30 +0000 (UTC) X-FDA: 81921410340.28.48578DE 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 6609B140014 for ; Thu, 21 Mar 2024 15:21:26 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=aculab.com; 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711034488; 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=kYx+yH1Aj2nSnhvJ5QA5m/irUHXe5Im4v01qYvy8Pq8=; b=GiqCgrCh6+fknqMVYdyBhrb1QNOyOO1KD44fkK+O70QM0aBfLVFcRggrvdehKj5HhffByb 4X6n/zq0ZMDXguN+W1Oq1o9M0pK/Tq1a3X5kQTPWwwfIgK8+4gE5EKM2a0AxsMRCOhXxpF i0PMzzDbQcGSixwq1vkbR3baA5HWj5E= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=aculab.com; 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 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711034488; a=rsa-sha256; cv=none; b=1N9jUPOwowajeDYTZTGqRFC6EUy5M6+AsH8vNTu9JhuXb756d7CvrS2FIPj4qtpboVvoyU cL3Iy9EI1oC4XsKGDOaDH2pRUJAX5MNJi6Fa9m9zEvzPD0ro9Zu73p3oE31cu9N+FTDb82 zXnxIfv9+6PIJbmHnJKFZrviIZzZvl4= 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-27-Q5suj0RZNn-WJXs-ToOs6A-1; Thu, 21 Mar 2024 15:21:23 +0000 X-MC-Unique: Q5suj0RZNn-WJXs-ToOs6A-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 15:20:57 +0000 Received: from AcuMS.Aculab.com ([::1]) by AcuMS.aculab.com ([::1]) with mapi id 15.00.1497.048; Thu, 21 Mar 2024 15:20:57 +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+nggAASTICAAASwMA== Date: Thu, 21 Mar 2024 15:20:57 +0000 Message-ID: <401453a216644af98d577f51c12d292b@AcuMS.aculab.com> References: <84a57ca8-8963-ca24-8bd1-ddc5c33bf4da@huawei.com> <0fd55e156195440bb1d815dd8300894b@AcuMS.aculab.com> <9d6057b110034c04b6b590522c8c69cc@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-Server: rspam09 X-Rspamd-Queue-Id: 6609B140014 X-Stat-Signature: fwkrjjtmhrzk7uf4sms6cywdb5cedkof X-Rspam-User: X-HE-Tag: 1711034486-21135 X-HE-Meta: U2FsdGVkX1+ebcGfYAZ6DpVBIb/IeIMM284DlbnLi2+9jWs8GnJRdw8IZbzEKDKiqm00UmGhha3/0OgxvPO5cuj3ohHfgVyjfmHxPZH57yt+N6aDWHQQ8o3fzXS3FbYtdHA0kHjPjO12c75PYLJ1soVvnIqgjRHqHgm1WmMkZHGJ2WttnjfqkfB5nxDx7BwqUqSgXVd8n7JPGx1Qge1klAAnMII1asT4kygJ7Nwin/aF/y7NCPzzpCLpG3xCtpOTOnfvmuOTsAiOkrsY3vaUECW5fLwiifgZ8XeSHl51D+h0Ua0CZiN2rccjcPrsN2XlkEhUK3UwSijeCi7BOsJj++DAyxRDHfzGy5LRS8QZBe6tVzGtIhKoHV1mIic01HBM9gh5TCGNN7EAq6flGC9zQrt0s/mgzKRSQjCmXPAO0crcEQIUM2zkhv5Dn+FAsCCjmIS4P55xugi+/7LDYMcZVyy4LZBp5J0r6qPclusnmmk0TnFai1z++OlKmLbNzVT5zjm36FI3Q9Xt0+8d02k7UN9oYDN8qHp13p/XnJhosgidEQf3XN2Z81kjm5aeOTgbiRizLzMhBS2O02YCH/0EXtDKcAaVTXti2At4so6uqtEwfOM20nIXji2DgZPbF5+rgQEBijiBa57+/sd+t6u4bRxbxmZqDXa5vyTunEtADG6ZjHM6/8ksvXkAiYSfj+22EXnnen2Jb7GItLQNBy4Xp45CAW8yH2uKNKIIIP1drVotzNih50vFgW5pblZAmF83NHhzt1hXi36PcWv78+3VmiWXr2w6alraEW950WHp3K7GpvWdiY/CQdM5//0RKR8sx+loZBsUzKoupHfnb5vzKIhBQTMCCmWQJpmSz250TB6LJcql7fSySLgqSsryYAumNkuio8Df6BQD+PqXXE9ohCe/zHw0k3uTcUdGOXp3kmbKwMivenxF9cpx15nUOK/p99f64/YCohF0WxF1jAB u+TDwCTX NC5MeVBvhYgKU+UGTwAKAiUD+aWYSVXAC76HUW8sNqYqH6UFKc/qcQ/9/0HuQAdMOa6lFKjQ9Ud8ynMMW7Xa4a9tUjIDoq/8To9nP7YCCOT+hRR2AjYbemaTieBTAtf0E24lfDeCtETFHNZYp74RZ1Xx2+8sugvD6PmuG9fKrwlqpwbA7hn38oKwTb3LlcGqm1LnvfOngbjDXjNG9iSuVuMpTWA8lmZIQfgFzNfVkR2aiDZEIQ8Jl6whJjUeU1kTfjutsqHyng+ytWGKKizF0i8BY59kBD3YDKrc2BBVmspJTcjo= 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 14:56 >=20 > On Thu, Mar 21, 2024 at 02:37:28PM +0000, David Laight wrote: > > From: Russell King > > > Sent: 21 March 2024 13:08 > > > > > > 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 b= e 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 i= n two > > > > > 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. > > > > > > 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. > > ... >=20 > Don't show me Arm64 assembly when we're discussing Arm32. Oops - I'd assumed no one did 32bit :-) In any case it is much the same, see https://godbolt.org/z/7dcbKrs76 f4: push {r3, lr} subs r3, r0, #0 ble .L2 mov r2, r3 mov r1, r3 bl f .L2: pop {r3, pc} f5: subs r3, r0, #0 ble .L6 push {lr} sub sp, sp, #12 mov r2, r3 mov r1, r3 str r3, [sp] bl f .L6: bx lr That is with -mno-sched-prolog but with 5+ args they spill to stack and the %sp change is pulled into the conditional. It does look like %lr is being saved (and for arm64 I think). =09David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales)