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
next prev parent 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: linkBe 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.