From 7b3e31869081771c63c3d006347ad06738f843b5 Mon Sep 17 00:00:00 2001 From: Chen Zhongjin Date: Thu, 18 Aug 2022 09:45:53 +0800 Subject: objtool: Use arch_jump_destination() in read_intra_function_calls() Use arch_jump_destiation() instead of the open-coded 'offset + len + immediate' that is x86 specific. Avoids future trouble with other architectures. Signed-off-by: Chen Zhongjin Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20220818014553.220261-1-chenzhongjin@huawei.com --- tools/objtool/check.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/objtool/check.c b/tools/objtool/check.c index 0cec74da7ffe..b012d987a658 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -2233,7 +2233,7 @@ static int read_intra_function_calls(struct objtool_file *file) */ insn->type = INSN_JUMP_UNCONDITIONAL; - dest_off = insn->offset + insn->len + insn->immediate; + dest_off = arch_jump_destination(insn); insn->jump_dest = find_insn(file, insn->sec, dest_off); if (!insn->jump_dest) { WARN_FUNC("can't find call dest at %s+0x%lx", -- cgit v1.2.3-70-g09d2 From 3c6f3900808c483b0bbb2c351f995c7b880dae14 Mon Sep 17 00:00:00 2001 From: Josh Poimboeuf Date: Thu, 18 Aug 2022 09:26:57 -0700 Subject: objtool: Remove "ANNOTATE_NOENDBR on ENDBR" warning This warning isn't very useful: why would you put ANNOTATE_NOENDBR on ENDBR, and if you did, what's the harm? And thus far it's only found one non-bug, where the '__end_entry_SYSENTER_compat' label happens to land on the ENDBR from entry_SYSCALL_compat: vmlinux.o: warning: objtool: entry_SYSCALL_compat+0x0: ANNOTATE_NOENDBR on ENDBR .. which is fine. Just remove the warning. Reported-by: kernel test robot Signed-off-by: Josh Poimboeuf Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/142341a5dafdfc788e4c95b9e226a6eefc9b626e.1660839773.git.jpoimboe@kernel.org --- tools/objtool/check.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/tools/objtool/check.c b/tools/objtool/check.c index b012d987a658..8b8c8f74a775 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -2102,9 +2102,6 @@ static int read_noendbr_hints(struct objtool_file *file) return -1; } - if (insn->type == INSN_ENDBR) - WARN_FUNC("ANNOTATE_NOENDBR on ENDBR", insn->sec, insn->offset); - insn->noendbr = 1; } -- cgit v1.2.3-70-g09d2 From 7a7621dfa417aa3715d2a3bd1bdd6cf5018274d0 Mon Sep 17 00:00:00 2001 From: Peter Zijlstra Date: Wed, 7 Sep 2022 11:01:20 +0200 Subject: objtool,x86: Teach decode about LOOP* instructions When 'discussing' control flow Masami mentioned the LOOP* instructions and I realized objtool doesn't decode them properly. As it turns out, these instructions are somewhat inefficient and as such unlikely to be emitted by the compiler (a few vmlinux.o checks can't find a single one) so this isn't critical, but still, best to decode them properly. Reported-by: Masami Hiramatsu (Google) Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/Yxhd4EMKyoFoH9y4@hirez.programming.kicks-ass.net --- tools/objtool/arch/x86/decode.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decode.c index c260006106be..1c253b4b7ce0 100644 --- a/tools/objtool/arch/x86/decode.c +++ b/tools/objtool/arch/x86/decode.c @@ -635,6 +635,12 @@ int arch_decode_instruction(struct objtool_file *file, const struct section *sec *type = INSN_CONTEXT_SWITCH; break; + case 0xe0: /* loopne */ + case 0xe1: /* loope */ + case 0xe2: /* loop */ + *type = INSN_JUMP_CONDITIONAL; + break; + case 0xe8: *type = INSN_CALL; /* -- cgit v1.2.3-70-g09d2