All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Indu Bhagat <indu.bhagat@oracle.com>
Cc: Fangrui Song <maskray@sourceware.org>,
	linux-toolchains@vger.kernel.org,
	 linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Concerns about SFrame viability for userspace stack walking
Date: Thu, 06 Nov 2025 08:51:22 +0100	[thread overview]
Message-ID: <lhuikfniop1.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <9c11b765-66df-46f3-b4ea-a0c7f52dac35@oracle.com> (Indu Bhagat's message of "Wed, 5 Nov 2025 16:44:24 -0800")

* Indu Bhagat:

> PLT stubs may use stack (push to stack). As per the document "A null
> frame (MODE = 8) is the simplest possible frame, with no allocated
> stack of either kind (hence no saved registers)".  So null frame can
> be used for PLT only if the functions invoking the PLT stub were using
> an RBP-based frame.  Isnt it ?

I think I said this before, but I don't think new toolchain features
need to support lazy binding.  Without lazy bindings, the PLT stubs do
not change the stack pointer or frame pointer and just make a tail call.

Do you see a need for continued support of lazy binding?

Thanks,
Florian


  reply	other threads:[~2025-11-06  7:51 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-30  6:53 Concerns about SFrame viability for userspace stack walking Fangrui Song
2025-10-30  7:30 ` Jakub Jelinek
2025-10-30  7:50   ` Fangrui Song
2025-10-30  8:05     ` Jakub Jelinek
2025-10-31  2:51       ` Fangrui Song
2025-10-30 10:26 ` Peter Zijlstra
2025-10-30 16:48   ` Fangrui Song
2025-10-30 17:03     ` Jose E. Marchesi
2025-10-31  4:22       ` Fangrui Song
2025-10-31 14:37         ` Jose E. Marchesi
2025-10-30 17:33     ` Steven Rostedt
2025-10-31  5:28       ` Fangrui Song
2025-10-30 18:22     ` Peter Zijlstra
2025-10-30 17:53   ` Andi Kleen
2025-10-30 18:07     ` Mark Brown
2025-10-30 18:31       ` Andi Kleen
2025-10-30 18:45         ` Mark Brown
2025-10-31  8:24           ` Fangrui Song
2025-10-30 18:57         ` Peter Zijlstra
2025-10-31 11:46           ` Mark Brown
2025-10-30 14:47 ` Jose E. Marchesi
2025-11-04  9:21 ` Indu
2025-11-05  8:21   ` Fangrui Song
2025-11-06  0:44     ` Indu Bhagat
2025-11-06  7:51       ` Florian Weimer [this message]
2025-11-06 21:02         ` Indu Bhagat
2025-11-06  9:20       ` Fangrui Song
2025-11-06 20:42         ` Indu Bhagat
2025-11-09  0:23           ` Fangrui Song
2025-12-01  9:04 ` Fangrui Song

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=lhuikfniop1.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=indu.bhagat@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-toolchains@vger.kernel.org \
    --cc=maskray@sourceware.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.