All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Sathvika Vasireddy <sv@linux.ibm.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Michael Ellerman <mpe@ellerman.id.au>,
	PowerPC <linuxppc-dev@lists.ozlabs.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
Subject: Re: linux-next: build warnings after merge of the powerpc-objtool tree
Date: Tue, 29 Nov 2022 15:28:49 +0000	[thread overview]
Message-ID: <c0ed0d60-6014-4c5f-e610-b4d3bd9e9e33@csgroup.eu> (raw)
In-Reply-To: <6cdad32e-782d-5bb5-f7e9-a44fb0b6444d@linux.ibm.com>



Le 29/11/2022 à 16:13, Sathvika Vasireddy a écrit :
> Hi all,
> 
> On 25/11/22 09:00, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the powerpc-objtool tree, today's linux-next build (powerpc
>> pseries_le_defconfig) produced these warnings:
>>
>> arch/powerpc/kernel/head_64.o: warning: objtool: end_first_256B(): 
>> can't find starting instruction
>> arch/powerpc/kernel/optprobes_head.o: warning: objtool: 
>> optprobe_template_end(): can't find starting instruction
>>
>> I have no idea what started this (they may have been there yesterday).
> I was able to recreate the above mentioned warnings with 
> pseries_le_defconfig and powernv_defconfig. The regression report also 
> mentions a warning 
> (https://lore.kernel.org/oe-kbuild-all/202211282102.QUr7HHrW-lkp@intel.com/) seen with arch/powerpc/kernel/kvm_emul.S assembly file.
> 
>   [1] arch/powerpc/kernel/optprobes_head.o: warning: objtool: 
> optprobe_template_end(): can't find starting instruction
>   [2] arch/powerpc/kernel/kvm_emul.o: warning: objtool: 
> kvm_template_end(): can't find starting instruction
>   [3] arch/powerpc/kernel/head_64.o: warning: objtool: end_first_256B(): 
> can't find starting instruction
> 
> The warnings [1] and [2] go away after adding 'nop' instruction. Below 
> diff fixes it for me:

You have to add NOPs just because those labels are at the end of the 
files. That's a bit odd.
I think either we are missing some kind of flagging for the symbols, or 
objtool has a bug. In both cases, I'm not sure adding an artificial 
'nop' is the solution. At least there should be a big hammer warning 
explaining why.

> 
> diff --git a/arch/powerpc/kernel/optprobes_head.S 
> b/arch/powerpc/kernel/optprobes_head.S
> index cd4e7bc32609..ea4e3bd82f4f 100644
> --- a/arch/powerpc/kernel/optprobes_head.S
> +++ b/arch/powerpc/kernel/optprobes_head.S
> @@ -134,3 +134,4 @@ optprobe_template_ret:
> 
>          .global optprobe_template_end
>   optprobe_template_end:
> +       nop
> 
> diff --git a/arch/powerpc/kernel/kvm_emul.S 
> b/arch/powerpc/kernel/kvm_emul.S
> index 7af6f8b50c5d..41fd664e3ba0 100644
> --- a/arch/powerpc/kernel/kvm_emul.S
> +++ b/arch/powerpc/kernel/kvm_emul.S
> @@ -352,3 +352,4 @@ kvm_tmp_end:
> 
>   .global kvm_template_end
>   kvm_template_end:
> +       nop
> 
> For warning [3], objtool is throwing can't find starting instruction 
> warning because it finds that the symbol (end_first_256B) is zero sized, 
> and such symbols are not added to the rbtree. I tried to fix it by 
> adding a 'nop' instruction (pasted diff below), but that resulted in a 
> kernel build failure.

What's the failure ?


> 
> diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
> index 874efd25cc45..d48850fe159f 100644
> --- a/arch/powerpc/kernel/head_64.S
> +++ b/arch/powerpc/kernel/head_64.S
> @@ -192,6 +192,7 @@ __secondary_hold:
>          EMIT_BUG_ENTRY 0b, __FILE__, __LINE__, 0
>   #endif
>   CLOSE_FIXED_SECTION(first_256B)
> +nop
> 
>   /*
>    * On server, we include the exception vectors code here as it
> 
> diff --git a/arch/powerpc/kernel/exceptions-64s.S 
> b/arch/powerpc/kernel/exceptions-64s.S
> index 26f8fef53c72..f7517d443e9b 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -3104,9 +3104,13 @@ __end_interrupts:
>   DEFINE_FIXED_SYMBOL(__end_interrupts, virt_trampolines)
> 
>   CLOSE_FIXED_SECTION(real_vectors);
> +nop
>   CLOSE_FIXED_SECTION(real_trampolines);
> +nop
>   CLOSE_FIXED_SECTION(virt_vectors);
> +nop
>   CLOSE_FIXED_SECTION(virt_trampolines);
> +nop

What are the NOPs after the CLOSE_FIXED_SECTION() ? You don't explain 
them, and I can't see any related warning in the warnings you show.



> 
>   USE_TEXT_SECTION()
> 
> I'm not very sure on how to address this particular warning 
> (arch/powerpc/kernel/head_64.o: warning: objtool: end_first_256B(): 
> can't find starting instruction). Given that there are no calls to 
> _mcount, one workaround is to skip objtool from running on 
> arch/powerpc/kernel/head_64.o file. The below diff works for me:
> 
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index 9b6146056e48..9ef6a040d875 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -219,3 +219,5 @@ $(obj)/vdso64_wrapper.o : $(obj)/vdso/vdso64.so.dbg
> 
>   # for cleaning
>   subdir- += vdso
> +
> +OBJECT_FILES_NON_STANDARD_head_64.o := y

Might be the solution, allthough I can't see other architectures doing that.

> 
> 
> Thanks,
> Sathvika

Christophe

WARNING: multiple messages have this Message-ID (diff)
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Sathvika Vasireddy <sv@linux.ibm.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Michael Ellerman <mpe@ellerman.id.au>,
	PowerPC <linuxppc-dev@lists.ozlabs.org>
Cc: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: linux-next: build warnings after merge of the powerpc-objtool tree
Date: Tue, 29 Nov 2022 15:28:49 +0000	[thread overview]
Message-ID: <c0ed0d60-6014-4c5f-e610-b4d3bd9e9e33@csgroup.eu> (raw)
In-Reply-To: <6cdad32e-782d-5bb5-f7e9-a44fb0b6444d@linux.ibm.com>



Le 29/11/2022 à 16:13, Sathvika Vasireddy a écrit :
> Hi all,
> 
> On 25/11/22 09:00, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the powerpc-objtool tree, today's linux-next build (powerpc
>> pseries_le_defconfig) produced these warnings:
>>
>> arch/powerpc/kernel/head_64.o: warning: objtool: end_first_256B(): 
>> can't find starting instruction
>> arch/powerpc/kernel/optprobes_head.o: warning: objtool: 
>> optprobe_template_end(): can't find starting instruction
>>
>> I have no idea what started this (they may have been there yesterday).
> I was able to recreate the above mentioned warnings with 
> pseries_le_defconfig and powernv_defconfig. The regression report also 
> mentions a warning 
> (https://lore.kernel.org/oe-kbuild-all/202211282102.QUr7HHrW-lkp@intel.com/) seen with arch/powerpc/kernel/kvm_emul.S assembly file.
> 
>   [1] arch/powerpc/kernel/optprobes_head.o: warning: objtool: 
> optprobe_template_end(): can't find starting instruction
>   [2] arch/powerpc/kernel/kvm_emul.o: warning: objtool: 
> kvm_template_end(): can't find starting instruction
>   [3] arch/powerpc/kernel/head_64.o: warning: objtool: end_first_256B(): 
> can't find starting instruction
> 
> The warnings [1] and [2] go away after adding 'nop' instruction. Below 
> diff fixes it for me:

You have to add NOPs just because those labels are at the end of the 
files. That's a bit odd.
I think either we are missing some kind of flagging for the symbols, or 
objtool has a bug. In both cases, I'm not sure adding an artificial 
'nop' is the solution. At least there should be a big hammer warning 
explaining why.

> 
> diff --git a/arch/powerpc/kernel/optprobes_head.S 
> b/arch/powerpc/kernel/optprobes_head.S
> index cd4e7bc32609..ea4e3bd82f4f 100644
> --- a/arch/powerpc/kernel/optprobes_head.S
> +++ b/arch/powerpc/kernel/optprobes_head.S
> @@ -134,3 +134,4 @@ optprobe_template_ret:
> 
>          .global optprobe_template_end
>   optprobe_template_end:
> +       nop
> 
> diff --git a/arch/powerpc/kernel/kvm_emul.S 
> b/arch/powerpc/kernel/kvm_emul.S
> index 7af6f8b50c5d..41fd664e3ba0 100644
> --- a/arch/powerpc/kernel/kvm_emul.S
> +++ b/arch/powerpc/kernel/kvm_emul.S
> @@ -352,3 +352,4 @@ kvm_tmp_end:
> 
>   .global kvm_template_end
>   kvm_template_end:
> +       nop
> 
> For warning [3], objtool is throwing can't find starting instruction 
> warning because it finds that the symbol (end_first_256B) is zero sized, 
> and such symbols are not added to the rbtree. I tried to fix it by 
> adding a 'nop' instruction (pasted diff below), but that resulted in a 
> kernel build failure.

What's the failure ?


> 
> diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
> index 874efd25cc45..d48850fe159f 100644
> --- a/arch/powerpc/kernel/head_64.S
> +++ b/arch/powerpc/kernel/head_64.S
> @@ -192,6 +192,7 @@ __secondary_hold:
>          EMIT_BUG_ENTRY 0b, __FILE__, __LINE__, 0
>   #endif
>   CLOSE_FIXED_SECTION(first_256B)
> +nop
> 
>   /*
>    * On server, we include the exception vectors code here as it
> 
> diff --git a/arch/powerpc/kernel/exceptions-64s.S 
> b/arch/powerpc/kernel/exceptions-64s.S
> index 26f8fef53c72..f7517d443e9b 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -3104,9 +3104,13 @@ __end_interrupts:
>   DEFINE_FIXED_SYMBOL(__end_interrupts, virt_trampolines)
> 
>   CLOSE_FIXED_SECTION(real_vectors);
> +nop
>   CLOSE_FIXED_SECTION(real_trampolines);
> +nop
>   CLOSE_FIXED_SECTION(virt_vectors);
> +nop
>   CLOSE_FIXED_SECTION(virt_trampolines);
> +nop

What are the NOPs after the CLOSE_FIXED_SECTION() ? You don't explain 
them, and I can't see any related warning in the warnings you show.



> 
>   USE_TEXT_SECTION()
> 
> I'm not very sure on how to address this particular warning 
> (arch/powerpc/kernel/head_64.o: warning: objtool: end_first_256B(): 
> can't find starting instruction). Given that there are no calls to 
> _mcount, one workaround is to skip objtool from running on 
> arch/powerpc/kernel/head_64.o file. The below diff works for me:
> 
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index 9b6146056e48..9ef6a040d875 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -219,3 +219,5 @@ $(obj)/vdso64_wrapper.o : $(obj)/vdso/vdso64.so.dbg
> 
>   # for cleaning
>   subdir- += vdso
> +
> +OBJECT_FILES_NON_STANDARD_head_64.o := y

Might be the solution, allthough I can't see other architectures doing that.

> 
> 
> Thanks,
> Sathvika

Christophe

  reply	other threads:[~2022-11-29 15:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-25  3:30 linux-next: build warnings after merge of the powerpc-objtool tree Stephen Rothwell
2022-11-25  3:30 ` Stephen Rothwell
2022-11-29 15:13 ` Sathvika Vasireddy
2022-11-29 15:13   ` Sathvika Vasireddy
2022-11-29 15:28   ` Christophe Leroy [this message]
2022-11-29 15:28     ` Christophe Leroy
2022-11-30 11:51     ` Sathvika Vasireddy
2022-11-30 11:51       ` Sathvika Vasireddy
2022-12-06 10:14       ` Naveen N. Rao
2022-12-06 10:14         ` Naveen N. Rao

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=c0ed0d60-6014-4c5f-e610-b4d3bd9e9e33@csgroup.eu \
    --to=christophe.leroy@csgroup.eu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --cc=sfr@canb.auug.org.au \
    --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.