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.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, 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 2DEBAC433DB for ; Thu, 4 Mar 2021 21:59:29 +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 5A92264FE4 for ; Thu, 4 Mar 2021 21:59:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5A92264FE4 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 4Ds4XG43prz3dC8 for ; Fri, 5 Mar 2021 08:59:26 +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 4Ds4Ww3LDzz3cPP for ; Fri, 5 Mar 2021 08:59:06 +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 124Lsnob015064; Thu, 4 Mar 2021 15:54:49 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 124Lsm4r015063; Thu, 4 Mar 2021 15:54:48 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 4 Mar 2021 15:54:48 -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: <20210304215448.GU29191@gate.crashing.org> References: <1802be3e-dc1a-52e0-1754-a40f0ea39658@csgroup.eu> <20210304145730.GC54534@C02TD0UTHF1T.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210304145730.GC54534@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 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. > Unless we can get some strong guarantees from compiler folk such that we > can guarantee a specific function acts boundary for unwinding (and > doesn't itself get split, etc), the only reliable way I can think to > solve this requires an assembly trampoline. Whatever we do is liable to > need some invasive rework. You cannot get such a guarantee, other than not letting the compiler see into the routine at all, like with assembler code (not inline asm, real assembler code). 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. Segher