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

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 458 bytes --]

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).

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 458 bytes --]

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).

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Sathvika Vasireddy]

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:

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.

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

  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


Thanks,
Sathvika

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

[Sathvika Vasireddy]

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:

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.

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

  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


Thanks,
Sathvika

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

[Christophe Leroy]

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

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

[Christophe Leroy]

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

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

[Sathvika Vasireddy]

On 29/11/22 20:58, Christophe Leroy wrote:
>
> 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.

I don't see these warnings with powerpc/topic/objtool branch. However, 
they are seen with linux-next master branch.
Commit dbcdbdfdf137b49144204571f1a5e5dc01b8aaad objtool: Rework 
instruction -> symbol mapping in linux-next is resulting in objtool 
can't find starting instruction warnings on powerpc.

Reverting this particular hunk (pasted below), resolves it and we don't 
see the problem anymore.

@@ -427,7 +427,10 @@ static int decode_instructions(struct objtool_file 
*file)
                 }

                 list_for_each_entry(func, &sec->symbol_list, list) {
-                       if (func->type != STT_FUNC || func->alias != func)
+                       if (func->type != STT_NOTYPE && func->type != 
STT_FUNC)
+                               continue;
+
+                       if (func->return_thunk || func->alias != func)
                                 continue;

                         if (!find_insn(file, sec, func->offset)) {

Peterz, can we ignore STT_NOTYPE symbols?

>> 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.
>
>
After fixing arch/powerpc/kernel/head_64.o: warning: objtool: 
end_first_256B(): can't find starting instruction warning, objtool 
started showing more warnings in the same file.
Below is the list of warnings:
  arch/powerpc/kernel/head_64.o: warning: objtool: end_real_vectors(): 
can't find starting instruction
  arch/powerpc/kernel/head_64.o: warning: objtool: 
end_real_trampolines(): can't find starting instruction
  arch/powerpc/kernel/head_64.o: warning: objtool: end_virt_vectors(): 
can't find starting instruction
  arch/powerpc/kernel/head_64.o: warning: objtool: 
end_virt_trampolines(): can't find starting instruction


Thanks,
Sathvika

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

[Sathvika Vasireddy]

On 29/11/22 20:58, Christophe Leroy wrote:
>
> 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.

I don't see these warnings with powerpc/topic/objtool branch. However, 
they are seen with linux-next master branch.
Commit dbcdbdfdf137b49144204571f1a5e5dc01b8aaad objtool: Rework 
instruction -> symbol mapping in linux-next is resulting in objtool 
can't find starting instruction warnings on powerpc.

Reverting this particular hunk (pasted below), resolves it and we don't 
see the problem anymore.

@@ -427,7 +427,10 @@ static int decode_instructions(struct objtool_file 
*file)
                 }

                 list_for_each_entry(func, &sec->symbol_list, list) {
-                       if (func->type != STT_FUNC || func->alias != func)
+                       if (func->type != STT_NOTYPE && func->type != 
STT_FUNC)
+                               continue;
+
+                       if (func->return_thunk || func->alias != func)
                                 continue;

                         if (!find_insn(file, sec, func->offset)) {

Peterz, can we ignore STT_NOTYPE symbols?

>> 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.
>
>
After fixing arch/powerpc/kernel/head_64.o: warning: objtool: 
end_first_256B(): can't find starting instruction warning, objtool 
started showing more warnings in the same file.
Below is the list of warnings:
  arch/powerpc/kernel/head_64.o: warning: objtool: end_real_vectors(): 
can't find starting instruction
  arch/powerpc/kernel/head_64.o: warning: objtool: 
end_real_trampolines(): can't find starting instruction
  arch/powerpc/kernel/head_64.o: warning: objtool: end_virt_vectors(): 
can't find starting instruction
  arch/powerpc/kernel/head_64.o: warning: objtool: 
end_virt_trampolines(): can't find starting instruction


Thanks,
Sathvika

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

[Naveen N. Rao]

Sathvika Vasireddy wrote:
> 
> On 29/11/22 20:58, Christophe Leroy wrote:
>>
>> 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.

The problem looks to be that commit dbcdbdfdf137b4 ("objtool: Rework 
instruction -> symbol mapping"), which was referenced by Sathvika below, 
changes how STT_NOTYPE symbols are handled. In the files throwing that 
warning, there are labels either at the very end of the file, or at the 
end of a section with no subsequent instruction. Before that commit, we 
didn't used to expect an instruction for STT_NOTYPE symbols.

> 
> I don't see these warnings with powerpc/topic/objtool branch. However, 
> they are seen with linux-next master branch.
> Commit dbcdbdfdf137b49144204571f1a5e5dc01b8aaad objtool: Rework 
> instruction -> symbol mapping in linux-next is resulting in objtool 
> can't find starting instruction warnings on powerpc.
> 
> Reverting this particular hunk (pasted below), resolves it and we don't 
> see the problem anymore.
> 
> @@ -427,7 +427,10 @@ static int decode_instructions(struct objtool_file 
> *file)
>                  }
> 
>                  list_for_each_entry(func, &sec->symbol_list, list) {
> -                       if (func->type != STT_FUNC || func->alias != func)
> +                       if (func->type != STT_NOTYPE && func->type != 
> STT_FUNC)
> +                               continue;
> +
> +                       if (func->return_thunk || func->alias != func)
>                                  continue;
> 
>                          if (!find_insn(file, sec, func->offset)) {

We are currently bailing out if find_insn() there fails. Should we 
instead just continue by not setting insn->sym?

@@ -430,11 +430,8 @@ static int decode_instructions(struct objtool_file *file)
                        if (func->return_thunk || func->alias != func)
                                continue;
 
-                       if (!find_insn(file, sec, func->offset)) {
-                               WARN("%s(): can't find starting instruction",
-                                    func->name);
-                               return -1;
-                       }
+                       if (!find_insn(file, sec, func->offset))
+                               continue;
 
                        sym_for_each_insn(file, func, insn) {
                                insn->sym = func;



- Naveen

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

[Naveen N. Rao]

Sathvika Vasireddy wrote:
> 
> On 29/11/22 20:58, Christophe Leroy wrote:
>>
>> 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.

The problem looks to be that commit dbcdbdfdf137b4 ("objtool: Rework 
instruction -> symbol mapping"), which was referenced by Sathvika below, 
changes how STT_NOTYPE symbols are handled. In the files throwing that 
warning, there are labels either at the very end of the file, or at the 
end of a section with no subsequent instruction. Before that commit, we 
didn't used to expect an instruction for STT_NOTYPE symbols.

> 
> I don't see these warnings with powerpc/topic/objtool branch. However, 
> they are seen with linux-next master branch.
> Commit dbcdbdfdf137b49144204571f1a5e5dc01b8aaad objtool: Rework 
> instruction -> symbol mapping in linux-next is resulting in objtool 
> can't find starting instruction warnings on powerpc.
> 
> Reverting this particular hunk (pasted below), resolves it and we don't 
> see the problem anymore.
> 
> @@ -427,7 +427,10 @@ static int decode_instructions(struct objtool_file 
> *file)
>                  }
> 
>                  list_for_each_entry(func, &sec->symbol_list, list) {
> -                       if (func->type != STT_FUNC || func->alias != func)
> +                       if (func->type != STT_NOTYPE && func->type != 
> STT_FUNC)
> +                               continue;
> +
> +                       if (func->return_thunk || func->alias != func)
>                                  continue;
> 
>                          if (!find_insn(file, sec, func->offset)) {

We are currently bailing out if find_insn() there fails. Should we 
instead just continue by not setting insn->sym?

@@ -430,11 +430,8 @@ static int decode_instructions(struct objtool_file *file)
                        if (func->return_thunk || func->alias != func)
                                continue;
 
-                       if (!find_insn(file, sec, func->offset)) {
-                               WARN("%s(): can't find starting instruction",
-                                    func->name);
-                               return -1;
-                       }
+                       if (!find_insn(file, sec, func->offset))
+                               continue;
 
                        sym_for_each_insn(file, func, insn) {
                                insn->sym = func;



- Naveen