arm: Replace ASSEMBLY with ASSEMBLER in uapi headers
PATCH v2 1/1 arm: Replace ASSEMBLY with ASSEMBLER in uapi headers
While the transition from __ASSEMBLY__ to __ASSEMBLER__ is not a regression, the use of the modern __ASSEMBLER__ macro requires a sufficiently recent compiler (GCC 3.0+).
In some environments, userland might still be using ancient tools like GCC 2.95.x, which does not natively define __ASSEMBLER__. To provide a complete fix and prevent silent build issues or header ambiguity, add an #error guard to catch unsupported toolchains.
Changes in v2:
- Added explicit #error check for GCC versions earlier than 3.0.
- Updated commit message to clarify the rationale for legacy toolchain support.
- Link to v1: https://lore.kernel.org/all/[email protected]/
--- arch/arm/include/uapi/asm/ptrace.h | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
arch/arm/include/uapi/asm/ptrace.h +7 -2
@@ -119,7 +119,12 @@#define PT_DATA_ADDR 0x10004#define PT_TEXT_END_ADDR 0x10008 -#ifndef __ASSEMBLY__ +#if defined(__GNUC__) && (__GNUC__ <3 ) +# error "GCC 3.0+ is required for proper __ASSEMBLER__ support. \ +Your compiler is too old to safely handle modern kernel assembly headers." +#endif + +#ifndef __ASSEMBLER__/* * This struct defines the way the registers are stored on the
@@ -158,6 +163,6 @@ struct pt_regs { #define ARM_VFPREGS_SIZE ( 32 * 8 /*fpregs*/ + 4 /*fpscr*/ ) -#endif /* __ASSEMBLY__ */ +#endif /* __ASSEMBLER__ */ #endif /* _UAPI__ASM_ARM_PTRACE_H */
Signature · 1 line
2.43.0
Quoted 24 lines · Nick Huang
While the transition from
__ASSEMBLY__to__ASSEMBLER__is not a regression, the use of the modern__ASSEMBLER__macro requires a sufficiently recent compiler (GCC 3.0+).In some environments, userland might still be using ancient tools like GCC 2.95.x, which does not natively define
__ASSEMBLER__. To provide a complete fix and prevent silent build issues or header ambiguity, add an #error guard to catch unsupported toolchains.Changes in v2:
- Added explicit #error check for GCC versions earlier than 3.0.
- Updated commit message to clarify the rationale for legacy toolchain support.
- Link to v1: https://lore.kernel.org/all/[email protected]/Signed-off-by Nick Huang <[email protected]>--- arch/arm/include/uapi/asm/ptrace.h | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)arch/arm/include/uapi/asm/ptrace.h +0
-0
arch/arm/include/uapi/asm/ptrace.h line 125
Quoted 8 lines
arch/arm/include/uapi/asm/ptrace.h +4
-1@@ -119,7 +119,12 @@#define PT_DATA_ADDR 0x10004#define PT_TEXT_END_ADDR 0x10008 -#ifndef __ASSEMBLY__ +#if defined(__GNUC__) && (__GNUC__ <3 ) +# error "GCC 3.0+ is required for proper __ASSEMBLER__ support. \ +Your compiler is too old to safely handle modern kernel assembly headers." +#endif
Having this check in a random, architecture-specific header does not make much sense. It should go into a generic header if we want to have it. Or we can have some generic postprocessing in 'headers_install'. But as most other architecture UAPI headers already have switched to __ASSEMBLER__, it seems nobody will be affected by this, so this check should be unnecessary.
Quoted 16 lines
arch/arm/include/uapi/asm/ptrace.h +3
-1+ +#ifndef __ASSEMBLER__/* * This struct defines the way the registers are stored on the @@ -158,6 +163,6 @@ struct pt_regs { #define ARM_VFPREGS_SIZE ( 32 * 8 /*fpregs*/ + 4 /*fpscr*/ ) -#endif /* __ASSEMBLY__ */ +#endif /* __ASSEMBLER__ */ #endif /* _UAPI__ASM_ARM_PTRACE_H */ Signature · 1 line
2.43.0
Thomas Weißschuh <[email protected]> 於 2026年2月28日週六 下午8:20寫道：
Quoted 8 lines
Quoted 8 lines
arch/arm/include/uapi/asm/ptrace.h +0
-0@@ -119,7 +119,12 @@#define PT_DATA_ADDR 0x10004#define PT_TEXT_END_ADDR 0x10008
Quoted 13 lines
arch/arm/include/uapi/asm/ptrace.h line 125
Quoted 5 lines
arch/arm/include/uapi/asm/ptrace.h +4
-1-#ifndef __ASSEMBLY__ +#if defined(__GNUC__) && (__GNUC__ <3 ) +# error "GCC 3.0+ is required for proper __ASSEMBLER__ support. \ +Your compiler is too old to safely handle modern kernel assembly headers." +#endif Having this check in a random, architecture-specific header does not make much sense. It should go into a generic header if we want to have it. Or we can have some generic postprocessing in '
headers_install'. But as most other architecture UAPI headers already have switched to__ASSEMBLER__, it seems nobody will be affected by this, so this check should be unnecessary.
Hi Thomas Weißschu
I'm aware that other architectures have transitioned to __ASSEMBLER__. However, I implemented this check here because Maciej W. Rozycki specifically suggested this approach during our discussion.
Signature · 2 lines
Regards, Nick Huang
Quoted 3 lines · Nick Huang
Quoted 3 lines
But as most other architecture UAPI headers already have switched to
__ASSEMBLER__, it seems nobody will be affected by this, so this check should be unnecessary.
It seems to whom? Have you got a reference to a discussion with libc
maintainers where the consensus has been that support for older compilers can be dropped? Why does it remain in the GNU C library?
Quoted 3 lines
I'm aware that other architectures have transitioned to
__ASSEMBLER__. However, I implemented this check here because Maciej W. Rozycki specifically suggested this approach during our discussion.
I asked a question whether this is relevant. The outcome could well be
that it is not, but with data available at hand such a conclusion cannot be made in my opinion.
Maciej
Quoted 9 lines · Maciej W. Rozycki
Quoted 3 lines · Nick Huang
Quoted 3 lines
But as most other architecture UAPI headers already have switched to
__ASSEMBLER__, it seems nobody will be affected by this, so this check should be unnecessary.It seems to whom? Have you got a reference to a discussion with libc
maintainers where the consensus has been that support for older compilers can be dropped? Why does it remain in the GNU C library?
To me, based on the fact that nobody has complained so far about the other architectures. But I don't really want to advocate for dropping compatibility.
Quoted 7 lines
Quoted 3 lines
I'm aware that other architectures have transitioned to
__ASSEMBLER__. However, I implemented this check here because Maciej W. Rozycki specifically suggested this approach during our discussion.I asked a question whether this is relevant. The outcome could well be
that it is not, but with data available at hand such a conclusion cannot be made in my opinion.
Fair enough. I have no issues with retaining the compatibility. But the approach in this patch is counterproductive to compatibility. For regular C sources, which I assume are most users of the UAPI headers, the __ASSEMBLER__ or __ASSEMBLY__ are wholly irrelevant. But with this patch they will be hard broken. Also UAPI consumers which might be perfectly happy to manually define __ASSEMBLY__ will now run into a hard error. So this check is strictly *less* compatible with exactly those old compilers.
Given that there is a general switch to __ASSEMBLY__ for regular kernel headers, the chances are high that adding these manual version checks to the UAPI headers will be forgotten frequently and will require a lot of fixups. If we want to stay compatible, we should do the following:
scripts/headers_install.sh +1 -0
@@ -36,6 +36,7 @@ sed -E -e ' s/(^|[^a-zA-Z0-9])__packed([^a-zA-Z0-9_]|$)/\1__attribute__((packed))\2/g s/(^|[[:space:](])(inline|asm|volatile)([[:space:](]|$)/\1__\2__\3/g s@#(ifndef|define|endif[[:space:]]*/[*])[[:space:]]*_UAPI@#\1 @ + s/__ASSEMBLY__/__ASSEMBLER__/g ' $INFILE > $TMPFILE || exit 1 scripts/unifdef -U__KERNEL__ -D__EXPORTED_HEADERS__ $TMPFILE > $OUTFILE
Then we can convert all UAPI headers to the in-kernel style using __ASSEMBLY__ and drop -DASSEMBLER from kbuild. Userspace will still work as before and if we come to the point to drop compatibility, we can do so far all UAPI headers at the same time, without any inconsistencies.
Right now I think the consistency argument is enough that this should have been done from the beginning. Your thoughts?
Thomas
Quoted 3 lines · Maciej W. Rozycki
It seems to whom? Have you got a reference to a discussion with libc maintainers where the consensus has been that support for older compilers can be dropped? Why does it remain in the GNU C library?
I have now consulted the glibc maintainers directly on this question. The thread is available here:
https://inbox.sourceware.org/libc-alpha/[email protected]/
Andreas Schwab (SUSE Labs) responded:
"Since the compiler will define __ASSEMBLER__ automatically when
preprocessing assembler-with-cpp files, there is no need to change anything on the glibc side. The places that define __ASSEMBLY__ for that purpose will just become redundant."
Best regards,
Nick Huang <[email protected]>
Re: [PATCH v2] arm: Replace ASSEMBLY with ASSEMBLER in uapi
In reply to Maciej W. RozyckiAdd a compatibility shim for __ASSEMBLER__ to support older GCC versions.
This bridge ensures that toolchains defining only __ASSEMBLY__ can correctly identify assembly stages.
This block can be removed once consensus is reached to drop support for these legacy compilers. If this version is acceptable, I will send it out in the v3 patch.
arch/arm/include/uapi/asm/ptrace.h +6 -2
@@ -119,7 +119,11 @@#define PT_DATA_ADDR 0x10004#define PT_TEXT_END_ADDR 0x10008 -#ifndef __ASSEMBLY__ +#if !defined(__ASSEMBLER__) && defined(__ASSEMBLY__) +#define __ASSEMBLER__ __ASSEMBLY__ +#endif + +#ifndef __ASSEMBLER__/* * This struct defines the way the registers are stored on the
@@ -158,6 +162,6 @@ struct pt_regs { #define ARM_VFPREGS_SIZE ( 32 * 8 /*fpregs*/ + 4 /*fpscr*/ ) -#endif /* __ASSEMBLY__ */ +#endif /* __ASSEMBLER__ */ #endif /* _UAPI__ASM_ARM_PTRACE_H */
Signature · 1 line
2.43.0
Re: [PATCH v2] arm: Replace ASSEMBLY with ASSEMBLER in uapi
Hi Nick,
thanks for the update. After our last discussion I prepared a supplemental patch for this, but of course forgot to actually send it out.
Quoted 9 lines · Nick Huang
Add a compatibility shim for
__ASSEMBLER__to support older GCC versions.
This bridge ensures that toolchains defining only__ASSEMBLY__can correctly identify assembly stages.
This block can be removed once consensus is reached to drop support for these legacy compilers. If this version is acceptable, I will send it out in the v3 patch.arch/arm/include/uapi/asm/ptrace.h +0
-0
arch/arm/include/uapi/asm/ptrace.h line 124
Quoted 7 lines
arch/arm/include/uapi/asm/ptrace.h +3
-1@@ -119,7 +119,11 @@#define PT_DATA_ADDR 0x10004#define PT_TEXT_END_ADDR 0x10008 -#ifndef __ASSEMBLY__ +#if !defined(__ASSEMBLER__) && defined(__ASSEMBLY__) +#define __ASSEMBLER__ __ASSEMBLY__ +#endif
With [0] this hunk should also be unnecesarry. It would free all UAPI authors from worrying about the problem at all.
Quoted 15 lines
arch/arm/include/uapi/asm/ptrace.h +2
-1+#ifndef __ASSEMBLER__/* * This struct defines the way the registers are stored on the @@ -158,6 +162,6 @@ struct pt_regs { #define ARM_VFPREGS_SIZE ( 32 * 8 /*fpregs*/ + 4 /*fpscr*/ ) -#endif /* __ASSEMBLY__ */ +#endif /* __ASSEMBLER__ */ #endif /* _UAPI__ASM_ARM_PTRACE_H */ Signature · 1 line
2.43.0
Re: [PATCH v2] arm: Replace ASSEMBLY with ASSEMBLER in uapi
Quoted 3 lines · Thomas Weißschuh
thanks for the update. After our last discussion I prepared a supplemental patch for this, but of course forgot to actually send it out.
I have now dug a bit deeper and realised that GCC used to have explicit
-D__ASSEMBLER__ in the specs for `@assembler-with-cpp' before switching to the internal macro definition. So I take my concern back, the original change is good to go in. Apologies for the confusion.
Maciej