linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jessica Clarke <jrtc27@jrtc27.com>
To: Andreas Schwab <schwab@linux-m68k.org>
Cc: Changbin Du <changbin.du@gmail.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] riscv: eliminate unreliable __builtin_frame_address(1)
Date: Wed, 19 Jan 2022 20:48:48 +0000	[thread overview]
Message-ID: <8F8D535F-3637-4BC7-8853-B709EC5D14C9@jrtc27.com> (raw)
In-Reply-To: <8735lj78wu.fsf@igel.home>

On 19 Jan 2022, at 20:44, Andreas Schwab <schwab@linux-m68k.org> wrote:
> 
> On Jan 19 2022, Jessica Clarke wrote:
> 
>> Leaf functions by definition don’t have callees that are trying to read
>> their frame pointer so aren’t relevant here.
> 
> ??? __builtin_frame_address(1) is about the caller, not the callee.

My point is that the only thing that can possibly read the incoming
frame pointer of a leaf function is the leaf function itself, and since
it knows where it’s putting it then there is no ABI issue, it just
remembers where it put it and loads it from there. The issue of whether
it’s part of the ABI or not only arises when you’re trying to read the
incoming frame pointer from a caller, which by definition is not a leaf
function.

Jess


  reply	other threads:[~2022-01-19 20:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-17 15:44 [PATCH] riscv: eliminate unreliable __builtin_frame_address(1) Changbin Du
2022-01-17 16:10 ` Andreas Schwab
2022-01-17 17:33 ` Jessica Clarke
2022-01-19 10:58   ` Andreas Schwab
2022-01-19 19:05     ` Jessica Clarke
2022-01-19 20:44       ` Andreas Schwab
2022-01-19 20:48         ` Jessica Clarke [this message]
2022-01-19 21:07           ` Andreas Schwab
2022-01-19 21:27             ` Jessica Clarke
2022-01-19 23:53               ` Andreas Schwab
2022-01-20  0:15                 ` Palmer Dabbelt
2022-02-04 21:56 ` Palmer Dabbelt

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=8F8D535F-3637-4BC7-8853-B709EC5D14C9@jrtc27.com \
    --to=jrtc27@jrtc27.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=changbin.du@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=schwab@linux-m68k.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).