Re: [PATCH v2 4/6] objtool/powerpc: Skip jump destination analysis and unnanotated intra-function call warnings for --ftr-fixup

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Sep 30, 2026 at 11:43:10AM +0530, Shivang Upadhyay wrote:
> On Tue, 2026-09-29 at 16:25 +0200, Peter Zijlstra wrote:
> > > c00000000002a610 <system_reset_exception>:
> > > c00000000002a610:       0e 01 4c 3c     addis   r2,r12,270
> > >                          c00000000002a610: R_PPC64_REL16_HA   
> > > .TOC.
> > > c00000000002a614:       f0 6c 42 38     addi    r2,r2,27888
> > >                          c00000000002a614: R_PPC64_REL16_LO   
> > > .TOC.+0x4
> > > c00000000002a618:       a6 02 08 7c     mflr    r0
> > > 
> > > This is happening because we should be looking for destination
> > > symbols that are at absolute offsets instead of relative offsets.
> > 
> > Again, confused. We run objtool on objects, this is pre-linking,
> > there
> > are no absolute offsets.
> Hi Peter,
> 
> This is the special requirement of patching jump assembly instructions
> that we need to know where the jump is performed from/to. As per 5/6
> objtool is run post link on vmlinux. If handling post-link information
> is outside the scope of objtool, please let me know.

I think we can make it work; but this wasn't immediately obvious. Also
I'm still struggling to understand what exactly you're doing -- I'm not
well versed in the PPC details and have no idea what this ftr thing
really is and your patches don't really explain anything much at all.

(Gemini is suggesting this is all somewhat similar to the x86 RIP
relative fixup we do for alternatives, but your case is more 'fun').

Anyway, I would much rather objtool learns how to deal with absolute
sections rather than making things depend on a 'random' ftr option. That
is, if we need conditional code, have it be because the secion has
non-zero address, not because ftr option or somesuch.

But noting that, can't we simply change:

  decode_instructions()
    hash_add(file->insn_hash, &insn->hash, sec_offset_hash(sec, insn->offset));

to take sh_addr into account? I mean, when unlinked, it'll be 0 so
nothing changes, but when already linked, it'll get you the absolute
value and then you don't need that fixup later on, or am I missing some
details?

So from where I'm at, please:

 - teach objtool about absolute sections, not ftr specials

 - expand changelog to actually explain what these ftr things are and
   how they work and what the actual problem is we're solving, so we
   don't need to employ LLMs to understand patches and all that :-)

Does that sound reasonable?