On Sat, Jul 29, 2023 at 09:59:23AM +0200, Arnd Bergmann wrote:
On Sat, Jul 29, 2023, at 01:44, Nathan Chancellor wrote:
On Fri, Jul 28, 2023 at 10:56:38PM +0200, Arnd Bergmann wrote:
DESCEND objtoolIn file included from /usr/include/aarch64-linux-gnu/asm/bitsperlong.h:1, from /usr/include/asm-generic/int-ll64.h:12, from /usr/include/asm-generic/types.h:7, from /usr/include/aarch64-linux-gnu/asm/types.h:1, from /linux-stable/tools/include/linux/types.h:13, from /linux-stable/tools/arch/x86/include/asm/orc_types.h:9, from /linux-stable/scripts/sorttable.h:96, from /linux-stable/scripts/sorttable.c:201: /linux-stable/tools/include/asm-generic/bitsperlong.h:14:2: error: #error Inconsistent word size. Check asm/bitsperlong.h 14 | #error Inconsistent word size. Check asm/bitsperlong.h | ^~~~~ make[3]: *** [/linux-stable/scripts/Makefile.host:114: scripts/sorttable] Error 1 ...
I also noticed that your command line includes CROSS_COMPILE=x86_64-linux- rather than CROSS_COMPILE=x86_64-linux-gnu-
Right, as I was reproducing this with your kernel.org GCC for CROSS_COMPILE and Fedora's GCC for HOSTCC, since I wanted to make sure this was not some issue with clang (which it does not appear to be).
Ok, it's beginning to make more sense to me now. I see that the tools/arch/x86/include/asm/orc_types.h comes from the x86_64 target build and is intentional, as sorttable.c needs to access the ORC information. Here the Makefile does
ifdef CONFIG_UNWINDER_ORC ifeq ($(ARCH),x86_64) ARCH := x86 endif HOSTCFLAGS_sorttable.o += -I$(srctree)/tools/arch/x86/include HOSTCFLAGS_sorttable.o += -DUNWINDER_ORC_ENABLED endif
in order to get the ORC definitions from asm/orc_types.h, but then it looks like it also gets the uapi/asm/bitsperlong.h header from there which contains
#if defined(__x86_64__) && !defined(__ILP32__) # define __BITS_PER_LONG 64 #else # define __BITS_PER_LONG 32 #endif
and this would set __BITS_PER_LONG to 32 on arm64.
However, I don't see this actually being included on my machine. Can you dump the sorttable.c preprocessor output with your setup, using -fdirectives-only, so we can see which of the two (__BITS_PER_LONG or BITS_PER_LONG) is actually wrong and triggers the sanity check?
Sure thing, this is the output of:
$ gcc -I/linux-stable/tools/include -I/linux-stable/tools/arch/x86/include -DUNWINDER_ORC_ENABLED -I ./scripts -E -fdirectives-only /linux-stable/scripts/sorttable.c
https://gist.github.com/nathanchance/d2c3e58230930317dc84aff80fef38bf
What I see on my machine is that both definitions come from the local tools/include/ headers, not from the installed system headers, so I'm still doing something wrong in my installation:
Just to make sure, you have the 6.5-rc1+ headers installed and you are attempting to build the host tools from an earlier Linux release than 6.5-rc1? I don't see a problem with building these host programs on mainline/6.5, I see this issue when building them in older stable releases (my reproduction so far has been on 6.4 but I see it when building all currently supported long term stable releases) when I have the 6.5-rc1+ headers installed.
./tools/include/uapi/asm-generic/bitsperlong.h #define __BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__)
Because this is the mainline version, whereas the stable version is:
#ifndef _UAPI__ASM_GENERIC_BITS_PER_LONG #define _UAPI__ASM_GENERIC_BITS_PER_LONG
/* * There seems to be no way of detecting this automatically from user * space, so 64 bit architectures should override this in their * bitsperlong.h. In particular, an architecture that supports * both 32 and 64 bit user space must not rely on CONFIG_64BIT * to decide it, but rather check a compiler provided macro. */ #ifndef __BITS_PER_LONG #define __BITS_PER_LONG 32 #endif
#endif /* _UAPI__ASM_GENERIC_BITS_PER_LONG */
which seems to be where the mismatch is coming from?
./tools/include/asm-generic/bitsperlong.h #define BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__)
Neither of these files actually contains the sanity check in linux-6.5-rc3, and comparing these is clearly nonsensical, as they are defined the same way (rather than checking CONFIG_64BIT), but also I don't see why there is both a uapi/ version and a non-uapi version in what is meant to be a userspace header.
May be worth looping in the tools/ folks, since that whole directory is rather special IMO...
Cheers, Nathan