v3: -- Check the definition of __BITS_PER_LONG first at the beginning of uapi/asm-generic/bitsperlong.h
v2: -- Check __CHAR_BIT__ and __SIZEOF_LONG__ rather than __aarch64__, __riscv, __loongarch__, thanks Ruoyao -- Update the code comment and commit message
v1: -- Rebase on 6.4-rc6 -- Only unify uapi bitsperlong.h for arm64, riscv and loongarch -- Remove uapi bitsperlong.h of hexagon and microblaze in a new patch
Here is the RFC patch: https://lore.kernel.org/linux-arch/1683615903-10862-1-git-send-email-yangtie...
Tiezhu Yang (2): asm-generic: Unify uapi bitsperlong.h for arm64, riscv and loongarch tools arch: Remove uapi bitsperlong.h of hexagon and microblaze
arch/arm64/include/uapi/asm/bitsperlong.h | 24 ------------------- arch/loongarch/include/uapi/asm/bitsperlong.h | 9 -------- arch/riscv/include/uapi/asm/bitsperlong.h | 14 ----------- include/uapi/asm-generic/bitsperlong.h | 13 ++++++++++- tools/arch/arm64/include/uapi/asm/bitsperlong.h | 24 ------------------- tools/arch/hexagon/include/uapi/asm/bitsperlong.h | 27 ---------------------- .../arch/loongarch/include/uapi/asm/bitsperlong.h | 9 -------- .../arch/microblaze/include/uapi/asm/bitsperlong.h | 2 -- tools/arch/riscv/include/uapi/asm/bitsperlong.h | 14 ----------- tools/include/uapi/asm-generic/bitsperlong.h | 14 ++++++++++- tools/include/uapi/asm/bitsperlong.h | 6 ----- 11 files changed, 25 insertions(+), 131 deletions(-) delete mode 100644 arch/arm64/include/uapi/asm/bitsperlong.h delete mode 100644 arch/loongarch/include/uapi/asm/bitsperlong.h delete mode 100644 arch/riscv/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/arm64/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/hexagon/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/loongarch/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/microblaze/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/riscv/include/uapi/asm/bitsperlong.h
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 --- arch/arm64/include/uapi/asm/bitsperlong.h | 24 ---------------------- arch/loongarch/include/uapi/asm/bitsperlong.h | 9 -------- arch/riscv/include/uapi/asm/bitsperlong.h | 14 ------------- include/uapi/asm-generic/bitsperlong.h | 13 +++++++++++- tools/arch/arm64/include/uapi/asm/bitsperlong.h | 24 ---------------------- .../arch/loongarch/include/uapi/asm/bitsperlong.h | 9 -------- tools/arch/riscv/include/uapi/asm/bitsperlong.h | 14 ------------- tools/include/uapi/asm-generic/bitsperlong.h | 14 ++++++++++++- tools/include/uapi/asm/bitsperlong.h | 6 ------ 9 files changed, 25 insertions(+), 102 deletions(-) delete mode 100644 arch/arm64/include/uapi/asm/bitsperlong.h delete mode 100644 arch/loongarch/include/uapi/asm/bitsperlong.h delete mode 100644 arch/riscv/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/arm64/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/loongarch/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/riscv/include/uapi/asm/bitsperlong.h
diff --git a/arch/arm64/include/uapi/asm/bitsperlong.h b/arch/arm64/include/uapi/asm/bitsperlong.h deleted file mode 100644 index 485d60be..0000000 --- a/arch/arm64/include/uapi/asm/bitsperlong.h +++ /dev/null @@ -1,24 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ -/* - * Copyright (C) 2012 ARM Ltd. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program. If not, see http://www.gnu.org/licenses/. - */ -#ifndef __ASM_BITSPERLONG_H -#define __ASM_BITSPERLONG_H - -#define __BITS_PER_LONG 64 - -#include <asm-generic/bitsperlong.h> - -#endif /* __ASM_BITSPERLONG_H */ diff --git a/arch/loongarch/include/uapi/asm/bitsperlong.h b/arch/loongarch/include/uapi/asm/bitsperlong.h deleted file mode 100644 index 00b4ba1..0000000 --- a/arch/loongarch/include/uapi/asm/bitsperlong.h +++ /dev/null @@ -1,9 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ -#ifndef __ASM_LOONGARCH_BITSPERLONG_H -#define __ASM_LOONGARCH_BITSPERLONG_H - -#define __BITS_PER_LONG (__SIZEOF_LONG__ * 8) - -#include <asm-generic/bitsperlong.h> - -#endif /* __ASM_LOONGARCH_BITSPERLONG_H */ diff --git a/arch/riscv/include/uapi/asm/bitsperlong.h b/arch/riscv/include/uapi/asm/bitsperlong.h deleted file mode 100644 index 7d0b32e..0000000 --- a/arch/riscv/include/uapi/asm/bitsperlong.h +++ /dev/null @@ -1,14 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0-only WITH Linux-syscall-note */ -/* - * Copyright (C) 2012 ARM Ltd. - * Copyright (C) 2015 Regents of the University of California - */ - -#ifndef _UAPI_ASM_RISCV_BITSPERLONG_H -#define _UAPI_ASM_RISCV_BITSPERLONG_H - -#define __BITS_PER_LONG (__SIZEOF_POINTER__ * 8) - -#include <asm-generic/bitsperlong.h> - -#endif /* _UAPI_ASM_RISCV_BITSPERLONG_H */ diff --git a/include/uapi/asm-generic/bitsperlong.h b/include/uapi/asm-generic/bitsperlong.h index 693d9a4..352cb81 100644 --- a/include/uapi/asm-generic/bitsperlong.h +++ b/include/uapi/asm-generic/bitsperlong.h @@ -2,6 +2,17 @@ #ifndef _UAPI__ASM_GENERIC_BITS_PER_LONG #define _UAPI__ASM_GENERIC_BITS_PER_LONG
+#ifndef __BITS_PER_LONG +/* + * In order to keep safe and avoid regression, only unify uapi + * bitsperlong.h for some archs which are using newer toolchains + * that have the definitions of __CHAR_BIT__ and __SIZEOF_LONG__. + * See the following link for more info: + * https://lore.kernel.org/linux-arch/b9624545-2c80-49a1-ac3c-39264a591f7b@app.... + */ +#if defined(__CHAR_BIT__) && defined(__SIZEOF_LONG__) +#define __BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__) +#else /* * There seems to be no way of detecting this automatically from user * space, so 64 bit architectures should override this in their @@ -9,8 +20,8 @@ * 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
#endif /* _UAPI__ASM_GENERIC_BITS_PER_LONG */ diff --git a/tools/arch/arm64/include/uapi/asm/bitsperlong.h b/tools/arch/arm64/include/uapi/asm/bitsperlong.h deleted file mode 100644 index 485d60be..0000000 --- a/tools/arch/arm64/include/uapi/asm/bitsperlong.h +++ /dev/null @@ -1,24 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ -/* - * Copyright (C) 2012 ARM Ltd. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program. If not, see http://www.gnu.org/licenses/. - */ -#ifndef __ASM_BITSPERLONG_H -#define __ASM_BITSPERLONG_H - -#define __BITS_PER_LONG 64 - -#include <asm-generic/bitsperlong.h> - -#endif /* __ASM_BITSPERLONG_H */ diff --git a/tools/arch/loongarch/include/uapi/asm/bitsperlong.h b/tools/arch/loongarch/include/uapi/asm/bitsperlong.h deleted file mode 100644 index 00b4ba1..0000000 --- a/tools/arch/loongarch/include/uapi/asm/bitsperlong.h +++ /dev/null @@ -1,9 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ -#ifndef __ASM_LOONGARCH_BITSPERLONG_H -#define __ASM_LOONGARCH_BITSPERLONG_H - -#define __BITS_PER_LONG (__SIZEOF_LONG__ * 8) - -#include <asm-generic/bitsperlong.h> - -#endif /* __ASM_LOONGARCH_BITSPERLONG_H */ diff --git a/tools/arch/riscv/include/uapi/asm/bitsperlong.h b/tools/arch/riscv/include/uapi/asm/bitsperlong.h deleted file mode 100644 index 0b9b58b..0000000 --- a/tools/arch/riscv/include/uapi/asm/bitsperlong.h +++ /dev/null @@ -1,14 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0-only */ -/* - * Copyright (C) 2012 ARM Ltd. - * Copyright (C) 2015 Regents of the University of California - */ - -#ifndef _UAPI_ASM_RISCV_BITSPERLONG_H -#define _UAPI_ASM_RISCV_BITSPERLONG_H - -#define __BITS_PER_LONG (__SIZEOF_POINTER__ * 8) - -#include <asm-generic/bitsperlong.h> - -#endif /* _UAPI_ASM_RISCV_BITSPERLONG_H */ diff --git a/tools/include/uapi/asm-generic/bitsperlong.h b/tools/include/uapi/asm-generic/bitsperlong.h index 23e6c41..352cb81 100644 --- a/tools/include/uapi/asm-generic/bitsperlong.h +++ b/tools/include/uapi/asm-generic/bitsperlong.h @@ -1,6 +1,18 @@ +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ #ifndef _UAPI__ASM_GENERIC_BITS_PER_LONG #define _UAPI__ASM_GENERIC_BITS_PER_LONG
+#ifndef __BITS_PER_LONG +/* + * In order to keep safe and avoid regression, only unify uapi + * bitsperlong.h for some archs which are using newer toolchains + * that have the definitions of __CHAR_BIT__ and __SIZEOF_LONG__. + * See the following link for more info: + * https://lore.kernel.org/linux-arch/b9624545-2c80-49a1-ac3c-39264a591f7b@app.... + */ +#if defined(__CHAR_BIT__) && defined(__SIZEOF_LONG__) +#define __BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__) +#else /* * There seems to be no way of detecting this automatically from user * space, so 64 bit architectures should override this in their @@ -8,8 +20,8 @@ * 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
#endif /* _UAPI__ASM_GENERIC_BITS_PER_LONG */ diff --git a/tools/include/uapi/asm/bitsperlong.h b/tools/include/uapi/asm/bitsperlong.h index da52065..c65267a 100644 --- a/tools/include/uapi/asm/bitsperlong.h +++ b/tools/include/uapi/asm/bitsperlong.h @@ -1,8 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0 */ #if defined(__i386__) || defined(__x86_64__) #include "../../../arch/x86/include/uapi/asm/bitsperlong.h" -#elif defined(__aarch64__) -#include "../../../arch/arm64/include/uapi/asm/bitsperlong.h" #elif defined(__powerpc__) #include "../../../arch/powerpc/include/uapi/asm/bitsperlong.h" #elif defined(__s390__) @@ -13,12 +11,8 @@ #include "../../../arch/mips/include/uapi/asm/bitsperlong.h" #elif defined(__ia64__) #include "../../../arch/ia64/include/uapi/asm/bitsperlong.h" -#elif defined(__riscv) -#include "../../../arch/riscv/include/uapi/asm/bitsperlong.h" #elif defined(__alpha__) #include "../../../arch/alpha/include/uapi/asm/bitsperlong.h" -#elif defined(__loongarch__) -#include "../../../arch/loongarch/include/uapi/asm/bitsperlong.h" #else #include <asm-generic/bitsperlong.h> #endif
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
arch/arm64/include/uapi/asm/bitsperlong.h | 24 ---------------------- arch/loongarch/include/uapi/asm/bitsperlong.h | 9 -------- arch/riscv/include/uapi/asm/bitsperlong.h | 14 ------------- include/uapi/asm-generic/bitsperlong.h | 13 +++++++++++- tools/arch/arm64/include/uapi/asm/bitsperlong.h | 24 ---------------------- .../arch/loongarch/include/uapi/asm/bitsperlong.h | 9 -------- tools/arch/riscv/include/uapi/asm/bitsperlong.h | 14 ------------- tools/include/uapi/asm-generic/bitsperlong.h | 14 ++++++++++++- tools/include/uapi/asm/bitsperlong.h | 6 ------ 9 files changed, 25 insertions(+), 102 deletions(-) delete mode 100644 arch/arm64/include/uapi/asm/bitsperlong.h delete mode 100644 arch/loongarch/include/uapi/asm/bitsperlong.h delete mode 100644 arch/riscv/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/arm64/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/loongarch/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/riscv/include/uapi/asm/bitsperlong.h
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 | ^~~~~
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.
Cheers, Nathan
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.
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 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.
Arnd
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
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 also noticed that your command line includes CROSS_COMPILE=x86_64-linux- rather than CROSS_COMPILE=x86_64-linux-gnu-, and I think we've had problems with that in the past, when "clang --target=x86_64-linux" fails to find the glibc system headers.
Arnd
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/36b9562acea404ecdc2911aeb2...
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
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?
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:
./tools/include/uapi/asm-generic/bitsperlong.h #define __BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__)
./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.
Arnd
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
On Sat, Jul 29, 2023, at 19:46, Nathan Chancellor wrote:
On Sat, Jul 29, 2023 at 09:59:23AM +0200, Arnd Bergmann wrote:
On Sat, Jul 29, 2023, at 01:44, Nathan Chancellor wrote:
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
Ok, so what we get is that the system-wide /usr/include/aarch64-linux-gnu/asm/bitsperlong.h
includes the source tree file tools/include/asm-generic/bitsperlong.h
which in the old kernels only has the "32" fallback value.
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.
Ok, I see. I missed that part of your description earlier.
which seems to be where the mismatch is coming from?
Right, exactly.
./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...
I think the good news is that this only happens because the tools/ directory contains a copy of the kernel headers including that sanity check, and other user space won't suffer from it because they don't contain copies of kernel internal headers.
Reverting the change might still end up being the easiest way out regardless, but it does seem like we should be able to address this in the tools directory by making sure it doesn't mix the installed headers with the local ones.
Part of the problem I think is that the installed /usr/include/asm-generic/int-ll64.h includes /usr/include/aarch64-linux-gnu/asm/bitsperlong.h, so both of them are the uapi headers, but this one has an "include <asm-generic/bitsperlong.h>" that expects the uapi version but instead gets the kernel version from the tools directory. We could override this by adding a working tools/include/asm-generic/bitsperlong.h header, but that has to be backported to the stable kernels then.
Arnd
On Sat, Jul 29, 2023 at 11:12:26PM +0200, Arnd Bergmann wrote:
On Sat, Jul 29, 2023, at 19:46, Nathan Chancellor wrote:
On Sat, Jul 29, 2023 at 09:59:23AM +0200, Arnd Bergmann wrote:
On Sat, Jul 29, 2023, at 01:44, Nathan Chancellor wrote:
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
Ok, so what we get is that the system-wide /usr/include/aarch64-linux-gnu/asm/bitsperlong.h
includes the source tree file tools/include/asm-generic/bitsperlong.h
which in the old kernels only has the "32" fallback value.
Ah, makes perfect sense.
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.
Ok, I see. I missed that part of your description earlier.
which seems to be where the mismatch is coming from?
Right, exactly.
./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...
I think the good news is that this only happens because the tools/ directory contains a copy of the kernel headers including that sanity check, and other user space won't suffer from it because they don't contain copies of kernel internal headers.
Yeah, I think you are correct.
Reverting the change might still end up being the easiest way out regardless, but it does seem like we should be able to address this in the tools directory by making sure it doesn't mix the installed headers with the local ones.
Agreed, although you do make a good point below that we would need the fix in the stable trees, which adds additional complexity when it comes to things like bisecting. It is already hard enough with all the various clang behavior changes we have had to adapt to over the years...
Part of the problem I think is that the installed /usr/include/asm-generic/int-ll64.h includes /usr/include/aarch64-linux-gnu/asm/bitsperlong.h, so both of them are the uapi headers, but this one has an "include <asm-generic/bitsperlong.h>" that expects the uapi version but instead gets the kernel version from the tools directory. We could override this by adding a working tools/include/asm-generic/bitsperlong.h header, but that has to be backported to the stable kernels then.
but this does not sound like it would be the end of the world, I do not have to bisect too often and even if I have to, using a userspace without these headers is generally possible.
Cheers, Nathan
After the following two commits:
commit 872e24d5c698 ("hexagon: remove asm/bitsperlong.h") commit 83f0124ad81e ("microblaze: remove asm-generic wrapper headers")
the arch-specific headers of hexagon and microblaze have been removed, the tools arch uapi headers are useless too, remove them.
Signed-off-by: Tiezhu Yang yangtiezhu@loongson.cn --- tools/arch/hexagon/include/uapi/asm/bitsperlong.h | 27 ---------------------- .../arch/microblaze/include/uapi/asm/bitsperlong.h | 2 -- 2 files changed, 29 deletions(-) delete mode 100644 tools/arch/hexagon/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/microblaze/include/uapi/asm/bitsperlong.h
diff --git a/tools/arch/hexagon/include/uapi/asm/bitsperlong.h b/tools/arch/hexagon/include/uapi/asm/bitsperlong.h deleted file mode 100644 index 5adca0d..0000000 --- a/tools/arch/hexagon/include/uapi/asm/bitsperlong.h +++ /dev/null @@ -1,27 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ -/* - * Copyright (c) 2010-2011, The Linux Foundation. All rights reserved. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 and - * only version 2 as published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA - * 02110-1301, USA. - */ - -#ifndef __ASM_HEXAGON_BITSPERLONG_H -#define __ASM_HEXAGON_BITSPERLONG_H - -#define __BITS_PER_LONG 32 - -#include <asm-generic/bitsperlong.h> - -#endif diff --git a/tools/arch/microblaze/include/uapi/asm/bitsperlong.h b/tools/arch/microblaze/include/uapi/asm/bitsperlong.h deleted file mode 100644 index 76da34b..0000000 --- a/tools/arch/microblaze/include/uapi/asm/bitsperlong.h +++ /dev/null @@ -1,2 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ -#include <asm-generic/bitsperlong.h>
On Thu, Jun 22, 2023, at 16:13, Tiezhu Yang wrote:
v3: -- Check the definition of __BITS_PER_LONG first at the beginning of uapi/asm-generic/bitsperlong.h
v2: -- Check __CHAR_BIT__ and __SIZEOF_LONG__ rather than __aarch64__, __riscv, __loongarch__, thanks Ruoyao -- Update the code comment and commit message
v1: -- Rebase on 6.4-rc6 -- Only unify uapi bitsperlong.h for arm64, riscv and loongarch -- Remove uapi bitsperlong.h of hexagon and microblaze in a new patch
Here is the RFC patch: https://lore.kernel.org/linux-arch/1683615903-10862-1-git-send-email-yangtie...
I've applied these to the asm-generic tree now
Thanks,
Arnd
On Thu, Jun 22, 2023 at 8:10 AM Arnd Bergmann arnd@arndb.de wrote:
On Thu, Jun 22, 2023, at 16:13, Tiezhu Yang wrote:
v3: -- Check the definition of __BITS_PER_LONG first at the beginning of uapi/asm-generic/bitsperlong.h
Thanks for doing this cleanup! I just wanted to report an issue I ran into with building the Linux perf tool. The header guard in: tools/include/asm-generic/bitsperlong.h https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tool...
Caused an issue with building: tools/perf/util/cs-etm.c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tool...
The issue was that cs-etm.c would #include a system header, which would transitively include a header with the same header guard. This led to the tools/include/asm-generic/bitsperlong.h being ignored and the compilation of tools/perf/util/cs-etm.c failing due to a missing define. My local workaround is:
``` diff --git a/tools/include/asm-generic/bitsperlong.h b/tools/include/asm-generic/bitsperlong.h index 2093d56ddd11..88508a35cb45 100644 --- a/tools/include/asm-generic/bitsperlong.h +++ b/tools/include/asm-generic/bitsperlong.h @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0 */ -#ifndef __ASM_GENERIC_BITS_PER_LONG -#define __ASM_GENERIC_BITS_PER_LONG +#ifndef __LINUX_TOOLS_ASM_GENERIC_BITS_PER_LONG +#define __LINUX_TOOLS_ASM_GENERIC_BITS_PER_LONG #include <uapi/asm-generic/bitsperlong.h> @@ -21,4 +21,4 @@ #define small_const_nbits(nbits) \ (__builtin_constant_p(nbits) && (nbits) <= BITS_PER_LONG && (nbits) > 0) -#endif /* __ASM_GENERIC_BITS_PER_LONG */ +#endif /* __LINUX_TOOLS_ASM_GENERIC_BITS_PER_LONG */ ```
I'm not sure if a wider fix is necessary for this, but I thought it worthwhile to report that there are potential issues. I don't think we can use #pragma once, as an alternative to header guards, to avoid this kind of name collision.
Thanks, Ian
v2: -- Check __CHAR_BIT__ and __SIZEOF_LONG__ rather than __aarch64__, __riscv, __loongarch__, thanks Ruoyao -- Update the code comment and commit message
v1: -- Rebase on 6.4-rc6 -- Only unify uapi bitsperlong.h for arm64, riscv and loongarch -- Remove uapi bitsperlong.h of hexagon and microblaze in a new patch
Here is the RFC patch: https://lore.kernel.org/linux-arch/1683615903-10862-1-git-send-email-yangtie...
I've applied these to the asm-generic tree now
Thanks,
Arnd
On Fri, Jul 14, 2023, at 20:34, Ian Rogers wrote:
On Thu, Jun 22, 2023 at 8:10 AM Arnd Bergmann arnd@arndb.de wrote:
On Thu, Jun 22, 2023, at 16:13, Tiezhu Yang wrote:
v3: -- Check the definition of __BITS_PER_LONG first at the beginning of uapi/asm-generic/bitsperlong.h
Thanks for doing this cleanup! I just wanted to report an issue I ran into with building the Linux perf tool. The header guard in: tools/include/asm-generic/bitsperlong.h https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tool...
Caused an issue with building: tools/perf/util/cs-etm.c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tool...
The issue was that cs-etm.c would #include a system header, which would transitively include a header with the same header guard. This led to the tools/include/asm-generic/bitsperlong.h being ignored and the compilation of tools/perf/util/cs-etm.c failing due to a missing define. My local workaround is:
diff --git a/tools/include/asm-generic/bitsperlong.h b/tools/include/asm-generic/bitsperlong.h index 2093d56ddd11..88508a35cb45 100644 --- a/tools/include/asm-generic/bitsperlong.h +++ b/tools/include/asm-generic/bitsperlong.h @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0 */ -#ifndef __ASM_GENERIC_BITS_PER_LONG -#define __ASM_GENERIC_BITS_PER_LONG +#ifndef __LINUX_TOOLS_ASM_GENERIC_BITS_PER_LONG +#define __LINUX_TOOLS_ASM_GENERIC_BITS_PER_LONG #include <uapi/asm-generic/bitsperlong.h> @@ -21,4 +21,4 @@ #define small_const_nbits(nbits) \ (__builtin_constant_p(nbits) && (nbits) <= BITS_PER_LONG && (nbits) > 0) -#endif /* __ASM_GENERIC_BITS_PER_LONG */ +#endif /* __LINUX_TOOLS_ASM_GENERIC_BITS_PER_LONG */I'm not sure if a wider fix is necessary for this, but I thought it worthwhile to report that there are potential issues. I don't think we can use #pragma once, as an alternative to header guards, to avoid this kind of name collision.
Thanks for the report! I think the correct fix is to update the tools/include/ headers to have the same change as the kernel itself. I don't know why we end up including both, that sounds like a separate issue but should normally be harmless as long as the contents are the same.
Arnd
linux-kselftest-mirror@lists.linaro.org
-
Arnd Bergmann -
Ian Rogers -
Nathan Chancellor -
Tiezhu Yang