From: Michael Ellerman <mpe@ellerman.id.au>
To: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>,
kernel test robot <lkp@intel.com>,
Sathvika Vasireddy <sv@linux.ibm.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>,
linux-kernel@vger.kernel.org, oe-kbuild-all@lists.linux.dev,
linuxppc-dev@lists.ozlabs.org, npiggin@gmail.com
Subject: Re: arch/powerpc/kernel/head_85xx.o: warning: objtool: .head.text+0x1a6c: unannotated intra-function call
Date: Wed, 25 Jan 2023 19:31:46 +1100 [thread overview]
Message-ID: <87v8kvow0d.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <1674631223.9e09lbzzb6.naveen@linux.ibm.com>
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> writes:
> Sathvika Vasireddy wrote:
>>
>>>>> arch/powerpc/kvm/booke.o: warning: objtool: kvmppc_fill_pt_regs+0x30: unannotated intra-function call
>>
>> As an attempt to fix it, I tried expanding ANNOTATE_INTRA_FUNCTION_CALL
>> macro to indicate that the branch target is valid. It then threw another
>> warning (arch/powerpc/kvm/booke.o: warning: objtool:
>> kvmppc_fill_pt_regs+0x38: intra_function_call not a direct call). The
>> below diff just removes the warnings for me, but I'm not very sure if
>> this is the best way to fix the objtool warnings seen with this
>> particular file. Please let me know if there are any better ways to fix it.
>>
>> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
>> index 0dce93ccaadf..b6a413824b98 100644
>> --- a/arch/powerpc/kvm/booke.c
>> +++ b/arch/powerpc/kvm/booke.c
>> @@ -917,7 +917,9 @@ static void kvmppc_fill_pt_regs(struct pt_regs *regs)
>> asm("mr %0, 1" : "=r"(r1));
>> asm("mflr %0" : "=r"(lr));
>> asm("mfmsr %0" : "=r"(msr));
>> + asm(".pushsection .discard.intra_function_calls; .long 999f;
>> .popsection; 999:");
>> asm("bl 1f; 1: mflr %0" : "=r"(ip));
>
> I don't think you can assume that there won't be anything in between two
> asm statements.
Yeah, compiler could interleave something theoretically.
> Even if that works, I don't think it is good to expand the macro here.
> That asm statement looks to be trying to grab the current nip. I don't
> know enough about that code, and someone who knows more about KVM may be
> able to help, but it looks like we should be able to simply set 'ip' to
> the address of kvmppc_fill_pt_regs()?
There is _THIS_IP_ which should be sufficient.
cheers
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>,
kernel test robot <lkp@intel.com>,
Sathvika Vasireddy <sv@linux.ibm.com>
Cc: npiggin@gmail.com, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, oe-kbuild-all@lists.linux.dev
Subject: Re: arch/powerpc/kernel/head_85xx.o: warning: objtool: .head.text+0x1a6c: unannotated intra-function call
Date: Wed, 25 Jan 2023 19:31:46 +1100 [thread overview]
Message-ID: <87v8kvow0d.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <1674631223.9e09lbzzb6.naveen@linux.ibm.com>
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> writes:
> Sathvika Vasireddy wrote:
>>
>>>>> arch/powerpc/kvm/booke.o: warning: objtool: kvmppc_fill_pt_regs+0x30: unannotated intra-function call
>>
>> As an attempt to fix it, I tried expanding ANNOTATE_INTRA_FUNCTION_CALL
>> macro to indicate that the branch target is valid. It then threw another
>> warning (arch/powerpc/kvm/booke.o: warning: objtool:
>> kvmppc_fill_pt_regs+0x38: intra_function_call not a direct call). The
>> below diff just removes the warnings for me, but I'm not very sure if
>> this is the best way to fix the objtool warnings seen with this
>> particular file. Please let me know if there are any better ways to fix it.
>>
>> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
>> index 0dce93ccaadf..b6a413824b98 100644
>> --- a/arch/powerpc/kvm/booke.c
>> +++ b/arch/powerpc/kvm/booke.c
>> @@ -917,7 +917,9 @@ static void kvmppc_fill_pt_regs(struct pt_regs *regs)
>> asm("mr %0, 1" : "=r"(r1));
>> asm("mflr %0" : "=r"(lr));
>> asm("mfmsr %0" : "=r"(msr));
>> + asm(".pushsection .discard.intra_function_calls; .long 999f;
>> .popsection; 999:");
>> asm("bl 1f; 1: mflr %0" : "=r"(ip));
>
> I don't think you can assume that there won't be anything in between two
> asm statements.
Yeah, compiler could interleave something theoretically.
> Even if that works, I don't think it is good to expand the macro here.
> That asm statement looks to be trying to grab the current nip. I don't
> know enough about that code, and someone who knows more about KVM may be
> able to help, but it looks like we should be able to simply set 'ip' to
> the address of kvmppc_fill_pt_regs()?
There is _THIS_IP_ which should be sufficient.
cheers
next prev parent reply other threads:[~2023-01-25 8:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-16 11:55 arch/powerpc/kernel/head_85xx.o: warning: objtool: .head.text+0x1a6c: unannotated intra-function call kernel test robot
2023-01-19 13:12 ` Sathvika Vasireddy
2023-01-25 7:27 ` Naveen N. Rao
2023-01-25 7:27 ` Naveen N. Rao
2023-01-25 8:31 ` Michael Ellerman [this message]
2023-01-25 8:31 ` Michael Ellerman
2023-01-26 18:05 ` Segher Boessenkool
2023-01-26 18:05 ` Segher Boessenkool
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v8kvow0d.fsf@mpe.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=christophe.leroy@csgroup.eu \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lkp@intel.com \
--cc=naveen.n.rao@linux.vnet.ibm.com \
--cc=npiggin@gmail.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=sv@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.