On Fri, Jul 28, 2023 at 10:56:38PM +0200, Arnd Bergmann wrote: > On Fri, Jul 28, 2023, at 19:31, Nathan Chancellor wrote: > > On Fri, Jul 28, 2023 at 01:00:30PM +0200, Arnd Bergmann wrote: > >> > >> of the uapi version. The sanity check in the kernel-side header > >> is intended to cross-check the CONFIG_64BIT value against the > >> __BITS_PER_LONG constant from the header. > >> > >> My first guess would be that this only worked by accident if the headers > >> defaulted to "#define __BITS_PER_LONG 32" in and #undef CONFIG_64BIT" > >> when include/generated/autoconf.h, but now the __BITS_PER_LONG value > >> is actually correct. > > > > That seems like a reasonable theory. I am still busy looking into other > > things today but I can try to double back to this on Monday if you don't > > make any progress. > > I tried reproducing this today on arm64 Debian with linux-6.5-rc3 > and clang-14.0.6 but I don't see the problem here. With 'make V=1' > I see command for building scripts/sorttable is > > clang -Wp,-MMD,scripts/.sorttable.d -Wall -Wmissing-prototypes \ > -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu11 \ > -I./tools/include -I./tools/arch/x86/include -DUNWINDER_ORC_ENABLED \ > -o scripts/sorttable scripts/sorttable.c -lpthread > > which does create an arm64 executable but includes the x86 headers, > which is clearly a bug by itself, it just doesn't trigger the problem > for me. I could not initially reproduce this on Debian either but I figured out why that might be: the default include paths on Debian look different from Fedora so just doing 'headers_install' into /usr will not reproduce this. If I add '-H' to that GCC command, Debian shows (I highlighted the key difference): . /linux-stable/scripts/sorttable.h .. /linux-stable/tools/arch/x86/include/asm/orc_types.h ... /linux-stable/tools/include/linux/types.h .... /usr/lib/gcc/aarch64-linux-gnu/12/include/stdbool.h .... /usr/lib/gcc/aarch64-linux-gnu/12/include/stddef.h .... /usr/include/aarch64-linux-gnu/asm/types.h ..... /usr/include/asm-generic/types.h ...... /usr/include/asm-generic/int-ll64.h ....... /usr/include/aarch64-linux-gnu/asm/bitsperlong.h <- ........ /linux-stable/tools/include/asm-generic/bitsperlong.h ......... /linux-stable/tools/include/uapi/asm-generic/bitsperlong.h Whereas Fedora shows: . /linux-stable/scripts/sorttable.h .. /linux-stable/tools/arch/x86/include/asm/orc_types.h ... /linux-stable/tools/include/linux/types.h .... /usr/lib/gcc/aarch64-redhat-linux/13/include/stdbool.h .... /usr/lib/gcc/aarch64-redhat-linux/13/include/stddef.h .... /usr/include/asm/types.h ..... /usr/include/asm-generic/types.h ...... /usr/include/asm-generic/int-ll64.h ....... /usr/include/asm/bitsperlong.h <- ........ /linux-stable/tools/include/asm-generic/bitsperlong.h ......... /linux-stable/tools/include/uapi/asm-generic/bitsperlong.h Running 'gcc -fsyntax-only -v -x c /dev/null' shows: Debian: #include <...> search starts here: /usr/lib/gcc/aarch64-linux-gnu/12/include /usr/local/include /usr/include/aarch64-linux-gnu /usr/include End of search list. Fedora: #include <...> search starts here: /usr/lib/gcc/aarch64-redhat-linux/13/include /usr/local/include /usr/include End of search list. It looks like Debian installs the architecture asm files into an architecture specific subdirectory, which headers_install does not know about, so the new "problematic" bitsperlong.h file gets installed to the default location but the older one actually gets used because it has higher priority in the include search path. https://salsa.debian.org/kernel-team/linux/-/blob/36b9562acea404ecdc2911aeb2c4539402f441a3/debian/rules.real#L334-336 If I install/manipulate the headers as Debian does, I can reproduce this issue in a fresh Debian container. # make -C /linux -j$(nproc) INSTALL_HDR_PATH=/usr O=/build headers_install # rm -fr /usr/include/aarch64-linux-gnu/asm # mv -v /usr/include/asm /usr/include/aarch64-linux-gnu # make -C /linux-stable -j$(nproc) ARCH=x86_64 CROSS_COMPILE=x86_64-linux-gnu- O=/build mrproper defconfig prepare ... DESCEND objtool In 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). Cheers, Nathan
