[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c0ed0d60-6014-4c5f-e610-b4d3bd9e9e33@csgroup.eu>
Date: Tue, 29 Nov 2022 15:28:49 +0000
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Sathvika Vasireddy <sv@...ux.ibm.com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Michael Ellerman <mpe@...erman.id.au>,
PowerPC <linuxppc-dev@...ts.ozlabs.org>
CC: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>,
"Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>
Subject: Re: linux-next: build warnings after merge of the powerpc-objtool
tree
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
Powered by blists - more mailing lists