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 09:00:00AM +0200, Peter Zijlstra wrote:
> On Tue, May 05, 2026 at 10:56:58AM -0500, Segher Boessenkool wrote:
> > On Tue, May 05, 2026 at 04:45:39PM +0200, Peter Zijlstra wrote:
> > > On Tue, May 05, 2026 at 02:16:23PM +0530, Sathvika Vasireddy wrote:
> > > >  	switch (opcode) {
> > > > +	case 16:
> > > 
> > > Like case 18 below, this wants a comment describing which instruction
> > > this is; bclr ?
> > 
> > Yes.  It is 19/16, b[c]lr (primary opcode 19, secondary opcode 16).
> > 
> > Where is it described what INSN_RETURN actually means for objtool?  Not
> > in the header file :-(
> 
> Yeah, nowhere much I'm afraid, it is very much organic growth that is
> firmly rooted in x86.
> 
> RETURN, along with sibling/tail CALLs validate things like the stack
> frame being in identical state as on function entry and a few other
> sanity checks (DF flag not set, no uaccess).

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

> There is also a pile of hacks around the whole return thunk mitigation
> thing. But that might be less relevant for other archs.

I don't really want to think about it :-)  Horrors!

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


Segher