linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Marco Elver <elver@google.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linuxppc-dev@lists.ozlabs.org,
	LKML <linux-kernel@vger.kernel.org>,
	kasan-dev <kasan-dev@googlegroups.com>,
	broonie@kernel.org, Paul Mackerras <paulus@samba.org>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends
Date: Thu, 4 Mar 2021 15:54:48 -0600	[thread overview]
Message-ID: <20210304215448.GU29191@gate.crashing.org> (raw)
In-Reply-To: <20210304145730.GC54534@C02TD0UTHF1T.local>

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

  parent reply	other threads:[~2021-03-04 21:59 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-03 14:09 [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends Christophe Leroy
2021-03-03 14:38 ` Marco Elver
2021-03-03 14:52   ` Christophe Leroy
2021-03-03 15:20     ` Marco Elver
2021-03-04 14:57       ` Mark Rutland
2021-03-04 15:30         ` Marco Elver
2021-03-04 16:59           ` Mark Rutland
2021-03-04 17:25             ` Marco Elver
2021-03-04 17:54               ` Nick Desaulniers
2021-03-04 19:24                 ` Segher Boessenkool
2021-03-05  6:38                   ` Christophe Leroy
2021-03-05 18:16                     ` Segher Boessenkool
2021-03-04 18:01               ` Mark Rutland
2021-03-04 18:22                 ` Marco Elver
2021-03-04 18:51                   ` Mark Rutland
2021-03-04 19:01                     ` Marco Elver
2021-03-05 12:04                       ` Mark Rutland
2021-03-04 21:54         ` Segher Boessenkool [this message]
2021-03-09 16:05           ` Mark Rutland
2021-03-09 22:05             ` Segher Boessenkool
2021-03-10 11:32               ` Mark Rutland
2021-03-10 17:37                 ` Segher Boessenkool

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210304215448.GU29191@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=elver@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mark.rutland@arm.com \
    --cc=paulus@samba.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).