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

From: Naveen N. Rao
Date: Tue Dec 06 2022 - 05:15:24 EST


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@xxxxxxxxx/) 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