[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <055e567d-771c-4031-952c-1bcdbf921c90@csgroup.eu>
Date: Mon, 24 Feb 2025 11:36:12 +0100
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Sathvika Vasireddy <sv@...ux.ibm.com>,
Josh Poimboeuf <jpoimboe@...nel.org>
Cc: peterz@...radead.org, npiggin@...il.com, maddy@...ux.ibm.com,
linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
llvm@...ts.linux.dev
Subject: Re: [RFC PATCH] objtool: Skip unannotated intra-function call warning
for bl+mflr pattern
Le 21/02/2025 à 09:50, Sathvika Vasireddy a écrit :
> [Vous ne recevez pas souvent de courriers de sv@...ux.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@...el.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@...ux.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
Powered by blists - more mailing lists