From: Julien Thierry <jthierry@xxxxxxxxxx>
The compiler can generate some '0x0' words in code sections to pad the
end of functions. Also some pesudo-instructions can generate data in
code sections.
Record these instructions which can't be decoded as ignored for
objtool check.
Signed-off-by: Julien Thierry <jthierry@xxxxxxxxxx>
Signed-off-by: Chen Zhongjin <chenzhongjin@xxxxxxxxxx>
---
tools/objtool/arch/arm64/decode.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/tools/objtool/arch/arm64/decode.c b/tools/objtool/arch/arm64/decode.c
index b62addece734..d2522ef43101 100644
--- a/tools/objtool/arch/arm64/decode.c
+++ b/tools/objtool/arch/arm64/decode.c
@@ -389,8 +389,23 @@ int arch_decode_instruction(struct objtool_file *file, const struct section *sec
switch (aarch64_get_insn_class(insn)) {
case AARCH64_INSN_CLS_UNKNOWN:
- WARN("can't decode instruction at %s:0x%lx", sec->name, offset);
- return -1;
+ /*
+ * There are a few reasons that non-valid opcodes in code sections:
+ * - For LDR ops, assembler can generate the data to be
+ * loaded in the code section
+ * - Compiler/assembler can generate zeroes to pad function that
+ * do not end on 8-byte alignment
+ * - Some pseudo-instructions can also generate data in code
+ * section
+ *
+ * Record these data as ignored so that they won't cause fault
+ */
+ if (insn == 0x0)
+ *type = INSN_NOP;
+ else if (record_invalid_insn(sec, offset, false))
+ return -1;
+
+ break;
case AARCH64_INSN_CLS_DP_IMM:
/* Mov register to and from SP are aliases of add_imm */
if (aarch64_insn_is_add_imm(insn) ||
--
2.17.1
