Re: [RFC PATCH] objtool: Skip unannotated intra-function call warning for bl+mflr pattern

[Christophe Leroy]

Le 21/02/2025 à 09:50, Sathvika Vasireddy a écrit :
> [Vous ne recevez pas souvent de courriers de sv@xxxxxxxxxxxxx. Découvrez 
> pourquoi ceci est important à https://aka.ms/ 
> LearnAboutSenderIdentification ]
>
> Hi Josh, Thanks for the review.
>
> On 2/21/25 1:29 AM, Josh Poimboeuf wrote:
> > On Wed, Feb 19, 2025 at 09:50:14PM +0530, Sathvika Vasireddy wrote:
> > > Architectures like PowerPC use a pattern where the compiler generates a
> > > branch-and-link (bl) instruction that targets the very next instruction,
> > > followed by loading the link register (mflr) later. This pattern appears
> > > in the code like:
> > >
> > >   bl .+4
> > >   li r5,0
> > >   mflr r30
> > If I understand correctly, this is basically a fake call which is used
> > to get the value of the program counter?
>
> Yes, that's correct.
>
> Also, just out of curiosity, how does x86 do it? Does it not use a
> branch to next instruction approach?
>
> > > Objtool currently warns about this as an "unannotated intra-function
> > > call" because find_call_destination() fails to find any symbol at the
> > > target offset. Add a check to skip the warning when a branch targets
> > > the immediate next instruction in the same function.
> > >
> > > Reported-by: kernel test robot <lkp@xxxxxxxxx>
> > > Closes: https://eur01.safelinks.protection.outlook.com/? 
> > > url=https%3A%2F%2Flore.kernel.org%2Foe-kbuild- 
> > > all%2F202502180818.XnFdv8I8- 
> > > lkp%40intel.com%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7Cdce2affdaed147a6058008dd5254d85e%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638757246560427230%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dhUS9PNZKUpz%2Bc1hePG1tuTIWbiKqS46uoAJOvU76sU%3D&reserved=0
> > > Signed-off-by: Sathvika Vasireddy <sv@xxxxxxxxxxxxx>
> > This should have a Fixes tag as well.
> Thanks for catching that. I'll add the Fixes tag.
> > >   static int add_call_destinations(struct objtool_file *file)
> > >   {
> > > +    struct instruction *next_insn;
> > >      struct instruction *insn;
> > >      unsigned long dest_off;
> > >      struct symbol *dest;
> > > @@ -1625,6 +1626,11 @@ static int add_call_destinations(struct 
> > > objtool_file *file)
> > >              reloc = insn_reloc(file, insn);
> > >              if (!reloc) {
> > >                      dest_off = arch_jump_destination(insn);
> > > +
> > > +                    next_insn = next_insn_same_func(file, insn);
> > > +                    if (next_insn && dest_off == next_insn->offset)
> > > +                            continue;
> > > +
> > This won't work on x86, where an intra-function call is converted to a
> > stack-modifying JUMP.  So this should probably be checked in an
> > arch-specific function.
>
> Thanks for letting me know, I'll introduce arch_skip_call_warning() to
> handle architecture specific cases in the next patch I send.

Not sure what you want to do here.

See my other response, I think it should just be handled as an 
INSN_OTHER by arch_decode_instruction()

Christophe