Re: [PATCH v1 1/6] objtool/powerpc: Add build-time fixup of alternate feature branch targets

Hi!

On Wed, May 06, 2026 at 04:22:14PM +0200, Peter Zijlstra wrote:

On Wed, May 06, 2026 at 08:58:57AM -0500, Segher Boessenkool wrote:

quoted

Huh.

On function entry, there is *no* accessible stack frame, on our ABIs
(typically you can still access your parent's frame of course, but then
you first need to find out who your parent is, etc.)  All stack frames
are always set up by separate store instructions.  We are a RISC
architecture after all (POWER means "Performance Optimisation With
Enhanced RISC").  So objtool checks if we actually tore down all
stack frames?  What a very useful thing to do.

Stack frames are a software concept in the first place, it has nothing
to do with the hardware, *at all*.  This is a bit different on archs
that *actually* have such a thing as a frame pointer, that don't emulate
it using a GPR (or something in memory!)

So, remember that objtool was born to generate ORC stack unwind data.
It needs to track the stack state at every instruction to accomplish
this.

Yup.

One of the basic sanity checks it does is ensuring there is no lingering
stack state on RETURN -- this would obviously cause the
caller/returned-to context to get a wee bit upset.

And yes, I realize this might sound quite mad to a compiler person. But

It doesn't sound weird *at all*, we have to jump through many hoops in
the compiler as well as in the ABIs to make this work at all.

remember that we have a ton of ASM (inline and otherwise) mixed in with
our C code. And while you can add DWARF CFI to ASM, this has
historically been a bit of a trainwreck, not in the least because the
annotations got wrong and nothing warned about it until the unwinder
would explode.

Typically, someone who writes inline assembler code cannot write CFI
statements properly *at all*, he/she just doesn't have all the necessary
information!  Only the compiler does.  It can put all kinds of stuff on
the stack for example.  Writing CFI statements manually is really forr
 someone writing machine code, or actual assembler code perhaps.

quoted

There are many other archs where all (or almost all, "all normal", call/
return sequences use a "link register", often called exactly that.  It's
the modern consensus to design call/return around that, I'd say even.
It would be nice if this abstraction worked well ;-)

Agreed. Its just that this thing has a very strong x86 flavour per its
legacy ;-) We'll get it sorted.

Thanks for the care!


Segher