Re: [tip: objtool/core] x86/insn: Support big endian cross-compiles

[Vasily Gorbik]

On Fri, Oct 09, 2020 at 10:49:21PM +0200, Borislav Petkov wrote:
> On Fri, Oct 09, 2020 at 10:38:22PM +0200, Peter Zijlstra wrote:
> > On Wed, Oct 07, 2020 at 04:20:19PM -0000, tip-bot2 for Martin Schwidefsky wrote:
> > > The following commit has been merged into the objtool/core branch of tip:
> > > 
> > > Commit-ID:     2a522b53c47051d3bf98748418f4f8e5f20d2c04
> > > Gitweb:        https://git.kernel.org/tip/2a522b53c47051d3bf98748418f4f8e5f20d2c04
> > > 
> > > x86/insn: Support big endian cross-compiles
> > 
> > This commit breaks the x86 build with CONFIG_X86_DECODER_SELFTEST=y.
> > 
> > I've asked Boris to truncate tip/objtool/core.
> 
> Yeah, top 4 are gone until this is resolved.
> 
> What I would suggest is to have a look at how tools/ headers are kept
> separate from kernel proper ones, see tools/include/ and how those
> headers there are full of dummy definitions just so it builds.
> 
> And then including a global one like linux/kernel.h is just looking for
> trouble:
> 
> In file included from ./include/uapi/linux/byteorder/little_endian.h:12,
>                  from ./include/linux/byteorder/little_endian.h:5,
>                  from /usr/include/x86_64-linux-gnu/asm/byteorder.h:5,
>                  from ./arch/x86/include/asm/insn.h:10,
>                  from arch/x86/tools/insn_sanity.c:21:
> ./tools/include/linux/types.h:30:18: error: conflicting types for ‘u64’
>    30 | typedef uint64_t u64;

Sigh... I have not realized there are more usages of insn.c which are
conditionally compiled. It's not like you grep *.c files to find who
includes them regularity.

Looks like there is no way to find common byte swapping helpers for
the kernel and tools then. Even though tools provide quite a bunch of
them in tools/include/. So, completely avoiding mixing "kernel" and
"userspace" headers would look like the following (delta to commit
mentioned above):
---

diff --git a/arch/x86/include/asm/insn.h b/arch/x86/include/asm/insn.h
index 004e27bdf121..68197fe18a11 100644
--- a/arch/x86/include/asm/insn.h
+++ b/arch/x86/include/asm/insn.h
@@ -7,7 +7,13 @@
  * Copyright (C) IBM Corporation, 2009
  */
 
+#ifdef __KERNEL__
 #include <asm/byteorder.h>
+#define insn_cpu_to_le32 cpu_to_le32
+#else
+#include <endian.h>
+#define insn_cpu_to_le32 htole32
+#endif
 /* insn_attr_t is defined in inat.h */
 #include <asm/inat.h>
 
@@ -47,7 +53,7 @@ static inline void insn_field_set(struct insn_field *p, insn_value_t v,
 				  unsigned char n)
 {
 	p->value = v;
-	p->little = __cpu_to_le32(v);
+	p->little = insn_cpu_to_le32(v);
 	p->nbytes = n;
 }
 
diff --git a/arch/x86/lib/insn.c b/arch/x86/lib/insn.c
index 520b31fc1f1a..003f32ff7798 100644
--- a/arch/x86/lib/insn.c
+++ b/arch/x86/lib/insn.c
@@ -5,7 +5,6 @@
  * Copyright (C) IBM Corporation, 2002, 2004, 2009
  */
 
-#include <linux/kernel.h>
 #ifdef __KERNEL__
 #include <linux/string.h>
 #else
@@ -16,15 +15,23 @@
 
 #include <asm/emulate_prefix.h>
 
+#ifdef __KERNEL__
+#define insn_le32_to_cpu le32_to_cpu
+#define insn_le16_to_cpu le16_to_cpu
+#else
+#define insn_le32_to_cpu le32toh
+#define insn_le16_to_cpu le16toh
+#endif
+
 #define leXX_to_cpu(t, r)						\
 ({									\
 	__typeof__(t) v;						\
 	switch (sizeof(t)) {						\
-	case 4: v = le32_to_cpu(r); break;				\
-	case 2: v = le16_to_cpu(r); break;				\
+	case 4: v = insn_le32_to_cpu(r); break;				\
+	case 2: v = insn_le16_to_cpu(r); break;				\
 	case 1:	v = r; break;						\
-	default:							\
-		BUILD_BUG(); break;					\
+	default: /* relying on -Wuninitialized to report this */	\
+		break;							\
 	}								\
 	v;								\
 })
--
And the same for the tools/*
No linux/kernel.h means no BUILD_BUG(), but -Wuninitialized actually
does a decent job in this case:
arch/x86/../../../arch/x86/lib/insn.c:605:37: error: variable 'v' is
		uninitialized when used here [-Werror,-Wuninitialized]
                insn_field_set(&insn->immediate2, get_next(long, insn), 1);
                                                  ^~~~~~~~~~~~~~~~~~~~

Masami, Josh,
would that be acceptable?

Should I resent the entire patch series again with these changes squashed?
Or just as a separate commit which would go on top?