Re: linux-next: build warnings after merge of the powerpc-objtool tree
From: Naveen N. Rao <hidden>
Date: 2022-12-06 10:15:24
Also in:
linux-next, lkml
Sathvika Vasireddy wrote:
On 29/11/22 20:58, Christophe Leroy wrote:quoted
Le 29/11/2022 à 16:13, Sathvika Vasireddy a écrit :quoted
Hi all, On 25/11/22 09:00, Stephen Rothwell wrote:quoted
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/ (local)) 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.
quoted hunk ↗ jump to hunk
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