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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 37244C4332D for ; Wed, 10 Mar 2021 17:45:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1B73F64F45 for ; Wed, 10 Mar 2021 17:45:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233289AbhCJRoy (ORCPT ); Wed, 10 Mar 2021 12:44:54 -0500 Received: from gate.crashing.org ([63.228.1.57]:57622 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233252AbhCJRom (ORCPT ); Wed, 10 Mar 2021 12:44:42 -0500 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 12AHbCRi007688; Wed, 10 Mar 2021 11:37:12 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 12AHbAOa007687; Wed, 10 Mar 2021 11:37:10 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 10 Mar 2021 11:37:10 -0600 From: Segher Boessenkool To: Mark Rutland Cc: Marco Elver , Catalin Marinas , Will Deacon , LKML , broonie@kernel.org, Paul Mackerras , kasan-dev , linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends Message-ID: <20210310173710.GL29191@gate.crashing.org> References: <1802be3e-dc1a-52e0-1754-a40f0ea39658@csgroup.eu> <20210304145730.GC54534@C02TD0UTHF1T.local> <20210304215448.GU29191@gate.crashing.org> <20210309160505.GA4979@C02TD0UTHF1T.local> <20210309220532.GI29191@gate.crashing.org> <20210310112441.GA19619@C02TD0UTHF1T.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210310112441.GA19619@C02TD0UTHF1T.local> User-Agent: Mutt/1.4.2.3i Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! On Wed, Mar 10, 2021 at 11:32:20AM +0000, Mark Rutland wrote: > On Tue, Mar 09, 2021 at 04:05:32PM -0600, Segher Boessenkool wrote: > > On Tue, Mar 09, 2021 at 04:05:23PM +0000, Mark Rutland wrote: > > > On Thu, Mar 04, 2021 at 03:54:48PM -0600, Segher Boessenkool wrote: > > > > On Thu, Mar 04, 2021 at 02:57:30PM +0000, Mark Rutland wrote: > > > > > It looks like GCC is happy to give us the function-entry-time FP if we use > > > > > __builtin_frame_address(1), > > > > > > > > From the GCC manual: > > > > Calling this function with a nonzero argument can have > > > > unpredictable effects, including crashing the calling program. As > > > > a result, calls that are considered unsafe are diagnosed when the > > > > '-Wframe-address' option is in effect. Such calls should only be > > > > made in debugging situations. > > > > > > > > It *does* warn (the warning is in -Wall btw), on both powerpc and > > > > aarch64. Furthermore, using this builtin causes lousy code (it forces > > > > the use of a frame pointer, which we normally try very hard to optimise > > > > away, for good reason). > > > > > > > > And, that warning is not an idle warning. Non-zero arguments to > > > > __builtin_frame_address can crash the program. It won't on simpler > > > > functions, but there is no real definition of what a simpler function > > > > *is*. It is meant for debugging, not for production use (this is also > > > > why no one has bothered to make it faster). > > > > > > > > On Power it should work, but on pretty much any other arch it won't. > > > > > > I understand this is true generally, and cannot be relied upon in > > > portable code. However as you hint here for Power, I believe that on > > > arm64 __builtin_frame_address(1) shouldn't crash the program due to the > > > way frame records work on arm64, but I'll go check with some local > > > compiler folk. I agree that __builtin_frame_address(2) and beyond > > > certainly can, e.g. by NULL dereference and similar. > > > > I still do not know the aarch64 ABI well enough. If only I had time! > > > > > For context, why do you think this would work on power specifically? I > > > wonder if our rationale is similar. > > > > On most 64-bit Power ABIs all stack frames are connected together as a > > linked list (which is updated atomically, importantly). This makes it > > possible to always find all previous stack frames. > > We have something similar on arm64, where the kernel depends on being > built with a frame pointer following the AAPCS frame pointer rules. The huge difference is on Power this is about the stack itself: you do not need a frame pointer at all for it (there is no specific register named as frame pointer, even). > Every stack frame contains a "frame record" *somewhere* within that > stack frame, and the frame records are chained together as a linked > list. The frame pointer points at the most recent frame record (and this > is what __builtin_frame_address(0) returns). > > See gcc.gnu.org/PR60109 for example. > > Sure; I see that being true generally (and Ramana noted that on 32-bit > arm a frame pointer wasn't mandated), but I think in this case we have a > stronger target (and configuration) specific guarantee. It sounds like it, yes. You need to have a frame pointer in the ABI, with pretty strong rules, and have everything follow those rules. > > Is the frame pointer required?! > > The arm64 Linux port mandates frame pointers for kernel code. It is > generally possible to build code without frame pointers (e.g. userspace), > but doing that for kernel code would be a bug. I see. And it even is less expensive to do this than on most machines, because of register pair load/store instructions :-) > > > > The real way forward is to bite the bullet and to no longer pretend you > > > > can do a full backtrace from just the stack contents. You cannot. > > > > > > I think what you mean here is that there's no reliable way to handle the > > > current/leaf function, right? If so I do agree. > > > > No, I meant what I said. > > > > There is the separate issue that you do not know where the return > > address (etc.) is stored in a function that has not yet done a call > > itself, sure. You cannot assume anything the ABI does not tell you you > > can depend on. > > This is in the frame record per the AAPCS. But you do not know where in the function it will store that. It often can be optimised by the compiler to only store the LR and FP on paths where a call will happen later, and there is no way (without DWARF info or similar) to know whether that has happened yet or not. This is a well-known problem of course. For the current function you cannot know in general if there is an activation frame yet or not. Segher 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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A8240C433E0 for ; Wed, 10 Mar 2021 17:41:52 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 348F564E01 for ; Wed, 10 Mar 2021 17:41:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 348F564E01 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4DwfXD2JQ0z3dJS for ; Thu, 11 Mar 2021 04:41:48 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=permerror (SPF Permanent Error: Unknown mechanism found: ip:192.40.192.88/32) smtp.mailfrom=kernel.crashing.org (client-ip=63.228.1.57; helo=gate.crashing.org; envelope-from=segher@kernel.crashing.org; receiver=) Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by lists.ozlabs.org (Postfix) with ESMTP id 4DwfWt1DVNz30LP for ; Thu, 11 Mar 2021 04:41:29 +1100 (AEDT) Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 12AHbCRi007688; Wed, 10 Mar 2021 11:37:12 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 12AHbAOa007687; Wed, 10 Mar 2021 11:37:10 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 10 Mar 2021 11:37:10 -0600 From: Segher Boessenkool To: Mark Rutland Subject: Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends Message-ID: <20210310173710.GL29191@gate.crashing.org> References: <1802be3e-dc1a-52e0-1754-a40f0ea39658@csgroup.eu> <20210304145730.GC54534@C02TD0UTHF1T.local> <20210304215448.GU29191@gate.crashing.org> <20210309160505.GA4979@C02TD0UTHF1T.local> <20210309220532.GI29191@gate.crashing.org> <20210310112441.GA19619@C02TD0UTHF1T.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210310112441.GA19619@C02TD0UTHF1T.local> User-Agent: Mutt/1.4.2.3i X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marco Elver , Catalin Marinas , linuxppc-dev@lists.ozlabs.org, LKML , kasan-dev , broonie@kernel.org, Paul Mackerras , Will Deacon , linux-arm-kernel@lists.infradead.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Hi! On Wed, Mar 10, 2021 at 11:32:20AM +0000, Mark Rutland wrote: > On Tue, Mar 09, 2021 at 04:05:32PM -0600, Segher Boessenkool wrote: > > On Tue, Mar 09, 2021 at 04:05:23PM +0000, Mark Rutland wrote: > > > On Thu, Mar 04, 2021 at 03:54:48PM -0600, Segher Boessenkool wrote: > > > > On Thu, Mar 04, 2021 at 02:57:30PM +0000, Mark Rutland wrote: > > > > > It looks like GCC is happy to give us the function-entry-time FP if we use > > > > > __builtin_frame_address(1), > > > > > > > > From the GCC manual: > > > > Calling this function with a nonzero argument can have > > > > unpredictable effects, including crashing the calling program. As > > > > a result, calls that are considered unsafe are diagnosed when the > > > > '-Wframe-address' option is in effect. Such calls should only be > > > > made in debugging situations. > > > > > > > > It *does* warn (the warning is in -Wall btw), on both powerpc and > > > > aarch64. Furthermore, using this builtin causes lousy code (it forces > > > > the use of a frame pointer, which we normally try very hard to optimise > > > > away, for good reason). > > > > > > > > And, that warning is not an idle warning. Non-zero arguments to > > > > __builtin_frame_address can crash the program. It won't on simpler > > > > functions, but there is no real definition of what a simpler function > > > > *is*. It is meant for debugging, not for production use (this is also > > > > why no one has bothered to make it faster). > > > > > > > > On Power it should work, but on pretty much any other arch it won't. > > > > > > I understand this is true generally, and cannot be relied upon in > > > portable code. However as you hint here for Power, I believe that on > > > arm64 __builtin_frame_address(1) shouldn't crash the program due to the > > > way frame records work on arm64, but I'll go check with some local > > > compiler folk. I agree that __builtin_frame_address(2) and beyond > > > certainly can, e.g. by NULL dereference and similar. > > > > I still do not know the aarch64 ABI well enough. If only I had time! > > > > > For context, why do you think this would work on power specifically? I > > > wonder if our rationale is similar. > > > > On most 64-bit Power ABIs all stack frames are connected together as a > > linked list (which is updated atomically, importantly). This makes it > > possible to always find all previous stack frames. > > We have something similar on arm64, where the kernel depends on being > built with a frame pointer following the AAPCS frame pointer rules. The huge difference is on Power this is about the stack itself: you do not need a frame pointer at all for it (there is no specific register named as frame pointer, even). > Every stack frame contains a "frame record" *somewhere* within that > stack frame, and the frame records are chained together as a linked > list. The frame pointer points at the most recent frame record (and this > is what __builtin_frame_address(0) returns). > > See gcc.gnu.org/PR60109 for example. > > Sure; I see that being true generally (and Ramana noted that on 32-bit > arm a frame pointer wasn't mandated), but I think in this case we have a > stronger target (and configuration) specific guarantee. It sounds like it, yes. You need to have a frame pointer in the ABI, with pretty strong rules, and have everything follow those rules. > > Is the frame pointer required?! > > The arm64 Linux port mandates frame pointers for kernel code. It is > generally possible to build code without frame pointers (e.g. userspace), > but doing that for kernel code would be a bug. I see. And it even is less expensive to do this than on most machines, because of register pair load/store instructions :-) > > > > The real way forward is to bite the bullet and to no longer pretend you > > > > can do a full backtrace from just the stack contents. You cannot. > > > > > > I think what you mean here is that there's no reliable way to handle the > > > current/leaf function, right? If so I do agree. > > > > No, I meant what I said. > > > > There is the separate issue that you do not know where the return > > address (etc.) is stored in a function that has not yet done a call > > itself, sure. You cannot assume anything the ABI does not tell you you > > can depend on. > > This is in the frame record per the AAPCS. But you do not know where in the function it will store that. It often can be optimised by the compiler to only store the LR and FP on paths where a call will happen later, and there is no way (without DWARF info or similar) to know whether that has happened yet or not. This is a well-known problem of course. For the current function you cannot know in general if there is an activation frame yet or not. Segher 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 X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4969AC433E0 for ; Wed, 10 Mar 2021 17:42:03 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C2FE660234 for ; Wed, 10 Mar 2021 17:42:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C2FE660234 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:Mime-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=R+24wz3HQcmnfa7r1x0m/jYzuDdM28xDGiuxsPeFSdo=; b=EsnjXLrgwVMWPr40g/gG6zsB6 3QnWEIbkbSOqhNyeOJM2qWIHVeZ626WLUpW6NgR8DAFwjji7H8oYdE4SzhzY5qslUEdanIUUfxlHr 8RZjNEj2pN0qtPKWvea/vn/7R5oWD9dYEIXAyjFxOf1XnV9cS3riHBSdD72eLggH2IEk+fNCMRPz+ OfISFOOsfCnpRjxgYphYgJAck3XnQZxrqEwjWhMOI/XWlszpAbM5a6AEA+76zAu3RVEvzpKkXFAcy d6G8QRqtpoFNiOx2Uvm1cOuoebqSsA7JVVmB80lHv4yGuR+LMVkm4YohfHj/8tgGOYFijOf+BSgT3 6ftK7xSYw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lK2ox-007MPh-5v; Wed, 10 Mar 2021 17:40:31 +0000 Received: from gate.crashing.org ([63.228.1.57]) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lK2oq-007MP3-Vf for linux-arm-kernel@lists.infradead.org; Wed, 10 Mar 2021 17:40:27 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 12AHbCRi007688; Wed, 10 Mar 2021 11:37:12 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 12AHbAOa007687; Wed, 10 Mar 2021 11:37:10 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 10 Mar 2021 11:37:10 -0600 From: Segher Boessenkool To: Mark Rutland Cc: Marco Elver , Catalin Marinas , Will Deacon , LKML , broonie@kernel.org, Paul Mackerras , kasan-dev , linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends Message-ID: <20210310173710.GL29191@gate.crashing.org> References: <1802be3e-dc1a-52e0-1754-a40f0ea39658@csgroup.eu> <20210304145730.GC54534@C02TD0UTHF1T.local> <20210304215448.GU29191@gate.crashing.org> <20210309160505.GA4979@C02TD0UTHF1T.local> <20210309220532.GI29191@gate.crashing.org> <20210310112441.GA19619@C02TD0UTHF1T.local> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210310112441.GA19619@C02TD0UTHF1T.local> User-Agent: Mutt/1.4.2.3i X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210310_174025_471325_7CDE111F X-CRM114-Status: GOOD ( 49.60 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi! On Wed, Mar 10, 2021 at 11:32:20AM +0000, Mark Rutland wrote: > On Tue, Mar 09, 2021 at 04:05:32PM -0600, Segher Boessenkool wrote: > > On Tue, Mar 09, 2021 at 04:05:23PM +0000, Mark Rutland wrote: > > > On Thu, Mar 04, 2021 at 03:54:48PM -0600, Segher Boessenkool wrote: > > > > On Thu, Mar 04, 2021 at 02:57:30PM +0000, Mark Rutland wrote: > > > > > It looks like GCC is happy to give us the function-entry-time FP if we use > > > > > __builtin_frame_address(1), > > > > > > > > From the GCC manual: > > > > Calling this function with a nonzero argument can have > > > > unpredictable effects, including crashing the calling program. As > > > > a result, calls that are considered unsafe are diagnosed when the > > > > '-Wframe-address' option is in effect. Such calls should only be > > > > made in debugging situations. > > > > > > > > It *does* warn (the warning is in -Wall btw), on both powerpc and > > > > aarch64. Furthermore, using this builtin causes lousy code (it forces > > > > the use of a frame pointer, which we normally try very hard to optimise > > > > away, for good reason). > > > > > > > > And, that warning is not an idle warning. Non-zero arguments to > > > > __builtin_frame_address can crash the program. It won't on simpler > > > > functions, but there is no real definition of what a simpler function > > > > *is*. It is meant for debugging, not for production use (this is also > > > > why no one has bothered to make it faster). > > > > > > > > On Power it should work, but on pretty much any other arch it won't. > > > > > > I understand this is true generally, and cannot be relied upon in > > > portable code. However as you hint here for Power, I believe that on > > > arm64 __builtin_frame_address(1) shouldn't crash the program due to the > > > way frame records work on arm64, but I'll go check with some local > > > compiler folk. I agree that __builtin_frame_address(2) and beyond > > > certainly can, e.g. by NULL dereference and similar. > > > > I still do not know the aarch64 ABI well enough. If only I had time! > > > > > For context, why do you think this would work on power specifically? I > > > wonder if our rationale is similar. > > > > On most 64-bit Power ABIs all stack frames are connected together as a > > linked list (which is updated atomically, importantly). This makes it > > possible to always find all previous stack frames. > > We have something similar on arm64, where the kernel depends on being > built with a frame pointer following the AAPCS frame pointer rules. The huge difference is on Power this is about the stack itself: you do not need a frame pointer at all for it (there is no specific register named as frame pointer, even). > Every stack frame contains a "frame record" *somewhere* within that > stack frame, and the frame records are chained together as a linked > list. The frame pointer points at the most recent frame record (and this > is what __builtin_frame_address(0) returns). > > See gcc.gnu.org/PR60109 for example. > > Sure; I see that being true generally (and Ramana noted that on 32-bit > arm a frame pointer wasn't mandated), but I think in this case we have a > stronger target (and configuration) specific guarantee. It sounds like it, yes. You need to have a frame pointer in the ABI, with pretty strong rules, and have everything follow those rules. > > Is the frame pointer required?! > > The arm64 Linux port mandates frame pointers for kernel code. It is > generally possible to build code without frame pointers (e.g. userspace), > but doing that for kernel code would be a bug. I see. And it even is less expensive to do this than on most machines, because of register pair load/store instructions :-) > > > > The real way forward is to bite the bullet and to no longer pretend you > > > > can do a full backtrace from just the stack contents. You cannot. > > > > > > I think what you mean here is that there's no reliable way to handle the > > > current/leaf function, right? If so I do agree. > > > > No, I meant what I said. > > > > There is the separate issue that you do not know where the return > > address (etc.) is stored in a function that has not yet done a call > > itself, sure. You cannot assume anything the ABI does not tell you you > > can depend on. > > This is in the frame record per the AAPCS. But you do not know where in the function it will store that. It often can be optimised by the compiler to only store the LR and FP on paths where a call will happen later, and there is no way (without DWARF info or similar) to know whether that has happened yet or not. This is a well-known problem of course. For the current function you cannot know in general if there is an activation frame yet or not. Segher _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel