Subject: Re: linux-next: build warnings after merge of the powerpc-objtool tree

From: Christophe Leroy <[email-masked]>
Date: Tue, 29 Nov 2022 15:28:49 +0000

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/[email-masked]/) 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