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

[Shivang Upadhyay <shivangu@linux.ibm.com>]

On Wed, 2026-09-30 at 11:44 +0200, Peter Zijlstra wrote:
> 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').
> 

Hi Peter,
Sorry for the delayed response.

I think I can explain the feature fixup mechanism and the problem we're
trying to solve more clearly in the cover letter.

Here is a basic example of what we're trying to achieve.

        GEN_COMMON data_access

            ld      r4,_DSISR(r1)
            addi    r3,r1,STACK_INT_FRAME_REGS
            andis.  r0,r4,DSISR_DABRMATCH@h
            bne-    1f

        #ifdef CONFIG_PPC_64S_HASH_MMU
        BEGIN_MMU_FTR_SECTION
            bl      CFUNC(do_hash_fault)
        MMU_FTR_SECTION_ELSE
            bl      CFUNC(do_page_fault)
        ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_TYPE_RADIX)
        #else
            bl      CFUNC(do_page_fault)
        #endif

            b       interrupt_return_srr

This is the implementation of the data_access exception handler on
ppc64le. Depending on whether the machine is using the hash or radix
MMU, we need to execute a different fault handler. The choice is made
at runtime based on the CPU's feature bits.

The assembly macros therefore generate code for both possible cases at
build time, and the feature-fixup mechanism later patches the code so
that only the appropriate path is executed.

The problem is that the linker does not know about this later patching
when it resolves branch relocations.
For example, consider:

feat_loc:
    ...

BEGIN_MMU_FTR_SECTION

    ...
loc_a:
    bl      CFUNC(main_feature)
    ...

MMU_FTR_SECTION_ELSE

    ...
loc_b:
    bl      CFUNC(alt_feature)
    ...

When linking this code, the linker will encode 
main_feature - loc_a at loc_a and alt_feature - loc_b at loc_b at two
bl instructions ablove.


However, alt_feature - loc_b is not the offset that we ultimately need
from the alt branch. When the feature fixup is applied, the instruction
at loc_a is replaced with the alternative instruction, so the branch
needs to encode (alt_feature - loc_a) jump.

This distinction matters because the branch displacement has to fit in
the range representable by the 32-bit PowerPC branch instruction.
Depending on where feat_loc, main_feature, and alt_feature end up after
linking, the linker-generated displacement can therefore be different
from the displacement that is actually needed after the feature fixup.
In some layouts this can result in either a build-time failure or, more
importantly, an invalid branch at runtime.

What we're trying to do with the build-time pass is detect these cases
and prepare the branch relocations for the code as it will actually
exist after feature patching. At minimum, it should allow us to detect
an impossible branch offset at build time rather than discovering it
only after the feature fixup is applied at runtime.


> 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
Sure I will try to rework these patches towards that.

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

Yes.

Thanks
~Shivang.