[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 at linux.ibm.com. 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 at intel.com>
>>> 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 at linux.ibm.com>
>> 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