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

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

Hi!

On Wed, May 06, 2026 at 09:00:00AM +0200, Peter Zijlstra wrote:

quoted

On Tue, May 05, 2026 at 10:56:58AM -0500, Segher Boessenkool wrote:

quoted

On Tue, May 05, 2026 at 04:45:39PM +0200, Peter Zijlstra wrote:

quoted

On Tue, May 05, 2026 at 02:16:23PM +0530, Sathvika Vasireddy wrote:

quoted

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

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.

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

Objtool solves all of that, by doing build time reconstruction of the
control flow and stack state it guarantees everything is consistent at
build time. Additionally it can deal with fun things like alternatives
/ static branches etc.

It can deal with both -fframe-pointer and -fomit-frame-pointer (on x86).
When the frame pointer reg (BP) is used, it also validates this is done
correctly.

This has caught many whoopsies over the years.

Then because this thing is parsing object files and decoding control
flow, features were added, like the uaccess scope checks.

quoted

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

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