On Fri, Jul 28, 2023 at 01:00:30PM +0200, Arnd Bergmann wrote:
On Thu, Jul 27, 2023, at 23:36, Nathan Chancellor wrote:
Hi Tiezhu and Arnd,
On Thu, Jun 22, 2023 at 10:13:38PM +0800, Tiezhu Yang wrote:
Now we specify the minimal version of GCC as 5.1 and Clang/LLVM as 11.0.0 in Documentation/process/changes.rst, __CHAR_BIT__ and __SIZEOF_LONG__ are usable, it is probably fine to unify the definition of __BITS_PER_LONG as (__CHAR_BIT__ * __SIZEOF_LONG__) in asm-generic uapi bitsperlong.h.
In order to keep safe and avoid regression, only unify uapi bitsperlong.h for some archs such as arm64, riscv and loongarch which are using newer toolchains that have the definitions of __CHAR_BIT__ and __SIZEOF_LONG__.
Suggested-by: Xi Ruoyao xry111@xry111.site Link: https://lore.kernel.org/all/d3e255e4746de44c9903c4433616d44ffcf18d1b.camel@x... Suggested-by: Arnd Bergmann arnd@arndb.de Link: https://lore.kernel.org/linux-arch/a3a4f48a-07d4-4ed9-bc53-5d383428bdd2@app.... Signed-off-by: Tiezhu Yang yangtiezhu@loongson.cn
I think this change has backwards compatibility concerns, as it breaks building certain host tools on the stable releases (at least 6.4 and 6.1, as that is where I noticed this). I see the following error on my aarch64 system:
$ make -skj"$(nproc)" ARCH=x86_64 CROSS_COMPILE=x86_64-linux- mrproper defconfig prepare In file included from /usr/include/asm/bitsperlong.h:1, from /usr/include/asm-generic/int-ll64.h:12, from /usr/include/asm-generic/types.h:7, from /usr/include/asm/types.h:1, from tools/include/linux/types.h:13, from tools/arch/x86/include/asm/orc_types.h:9, from scripts/sorttable.h:96, from scripts/sorttable.c:201: 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 | ^~~~~
Thanks for the report. I'm still struggling to figure out what exactly is going wrong here, and if this is a bug in the patch I merged, or an existing bug that now causes a build failure instead of some other problem.
Totally understandable, I was really confused at first too.
A reverse bisect of 6.4 to 6.5-rc1 points to this patch. This Fedora rawhide container has kernel-headers 6.5.0-0.rc2.git0.1.fc39 and the error disappears when I downgrade to 6.4.0-0.rc7.git0.1.fc39. I have not done a ton of triage/debugging so far, as I am currently hunting down other regressions, but I figured I would get an initial report out, since I noticed it when validating LLVM from the new release/17.x branch. If there is any additional information I can provide or patches I can test, I am more than happy to do so.
One thing I think is going wrong here is that scripts/sorttable.c is meant to run on the host (arm64) but includes the target (x86) orc_Types.h header and the kernel-internal asm/bitsperlong.h instead
Right. I will note sorttable is not the only utility that has this issue, I see the same problem coming from several files in tools/lib/subcmd when building several different architectures and arch/x86/entry/vdso/vdso2c.c at the very least.
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.
Cheers, Nathan