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

[Segher Boessenkool <segher@kernel.crashing.org>]

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:
> > 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.

> > 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