[RFC PATCH v3 10/13] objtool: arm64: Accept non-instruction data in code sections

[Chen Zhongjin]

From: Julien Thierry <jthierry at redhat.com>

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 at redhat.com>
Signed-off-by: Chen Zhongjin <chenzhongjin at huawei.com>
---
 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