[PATCH 0/3] check-uapi: improve portability for testing headers

[PATCH 0/3] check-uapi: improve portability for testing headers

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

While working on a series to clean up some uapi headers, I needed
to check the that the actual ABI remains unchanged. I found that
scripts/check-uapi.sh works well enough for architectures that have a
full toolchain installed, but not with the nolibc compilers I provide
on kernel.org.

I ended up with a series addressing three separate issues here, but in
the end I can now validate ABI changes across all supported architectures
and ABIs.

The third patch depends on a series from Thomas Weißschuh that was
just merged into the kbuild-for-next tree, the other ones could
also apply to older kernels. I have marked the second patch for
backports to stable kernels, this one is what caused me the most
work in debugging.

    Arnd

Arnd Bergmann (3):
  check-uapi: link into shared objects
  check-uapi: honor ${CROSS_COMPILE} setting
  check-uapi: use dummy libc includes

 scripts/check-uapi.sh | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

-- 
2.39.5
Cc: Dodji Seketeli <dodji@seketeli.org>
Cc: John Moon <john@jmoon.dev>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nicolas Schier <nsc@kernel.org>
Cc: Thomas Weißschuh <linux@weissschuh.net>
Cc: libabigail@sourceware.org
Cc: linux-kbuild@vger.kernel.org

[PATCH 1/3] check-uapi: link into shared objects

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

While testing ABI changes across all architectures, I found that abidiff
sometimes produces nonsensical output. Further debugging identified
missing or broken libelf support for architecture specific relocations
in ET_REL binaries as the source of the problem[1].

Change the script to no longer produce a relocatable object file but
instead create a shared library for each header. This makes abidiff
work for all of the architectures in upstream linux kernels.

Link: https://sourceware.org/bugzilla/show_bug.cgi?id=33869
Cc: stable@vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 scripts/check-uapi.sh | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/scripts/check-uapi.sh b/scripts/check-uapi.sh
index 955581735cb3..9fa45cbdecc2 100755
--- a/scripts/check-uapi.sh
+++ b/scripts/check-uapi.sh
@@ -178,8 +178,11 @@ do_compile() {
 	local -r inc_dir="$1"
 	local -r header="$2"
 	local -r out="$3"
-	printf "int main(void) { return 0; }\n" | \
-		"$CC" -c \
+	printf "int f(void) { return 0; }\n" | \
+		"$CC" \
+		  -shared \
+		  -nostdlib \
+		  -fPIC \
 		  -o "$out" \
 		  -x c \
 		  -O0 \
-- 
2.39.5

[PATCH 2/3] check-uapi: honor ${CROSS_COMPILE} setting

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

When ${CROSS_COMPILE} is set, but ${CC} is not set, the logic in
check-uapi.sh is different from the top-level Makefile, which defaults
to using the cross gcc. This leads to using the native gcc instead of the
cross version, resulting in unexpected false-positive and false-negative
output.

Use the same logic here that we use in Kbuild for consistency.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 scripts/check-uapi.sh | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/scripts/check-uapi.sh b/scripts/check-uapi.sh
index 9fa45cbdecc2..e4d120eb09e3 100755
--- a/scripts/check-uapi.sh
+++ b/scripts/check-uapi.sh
@@ -33,9 +33,10 @@ Options:
     -v             Verbose operation (print more information about each header being checked).
 
 Environmental args:
-    ABIDIFF  Custom path to abidiff binary
-    CC       C compiler (default is "gcc")
-    ARCH     Target architecture for the UAPI check (default is host arch)
+    ABIDIFF        Custom path to abidiff binary
+    CROSS_COMPILE  Toolchain prefix for compiler
+    CC             C compiler (default is "\${CROSS_COMPILE}gcc")
+    ARCH           Target architecture for the UAPI check (default is host arch)
 
 Exit codes:
     $SUCCESS) Success
@@ -198,7 +199,7 @@ do_compile() {
 run_make_headers_install() {
 	local -r ref="$1"
 	local -r install_dir="$(get_header_tree "$ref")"
-	make -j "$MAX_THREADS" ARCH="$ARCH" INSTALL_HDR_PATH="$install_dir" \
+	make -j "$MAX_THREADS" CROSS_COMPILE="${CROSS_COMPILE}" ARCH="$ARCH" INSTALL_HDR_PATH="$install_dir" \
 		headers_install > /dev/null
 }
 
@@ -407,7 +408,7 @@ min_version_is_satisfied() {
 # Make sure we have the tools we need and the arguments make sense
 check_deps() {
 	ABIDIFF="${ABIDIFF:-abidiff}"
-	CC="${CC:-gcc}"
+	CC="${CC:-${CROSS_COMPILE}gcc}"
 	ARCH="${ARCH:-$(uname -m)}"
 	if [ "$ARCH" = "x86_64" ]; then
 		ARCH="x86"
-- 
2.39.5

[PATCH 3/3] check-uapi: use dummy libc includes

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

Based on Thomas Weißschuh's series to kernel headers to no longer require
an installed libc when build testing the uapi headers, the same can now
be done for the scripts/check-uapi.sh script.

The only required change here is to add the  usr/dummy-include include
path.

Link: https://lore.kernel.org/lkml/20260227-kbuild-uapi-libc-v1-0-c17de0d19776@weissschuh.net/ [1]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 scripts/check-uapi.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/check-uapi.sh b/scripts/check-uapi.sh
index e4d120eb09e3..c8beec58871c 100755
--- a/scripts/check-uapi.sh
+++ b/scripts/check-uapi.sh
@@ -191,6 +191,7 @@ do_compile() {
 		  -fno-eliminate-unused-debug-types \
 		  -g \
 		  "-I${inc_dir}" \
+		  "-Iusr/dummy-include" \
 		  -include "$header" \
 		  -
 }
-- 
2.39.5

Re: [PATCH 3/3] check-uapi: use dummy libc includes

[Thomas Weißschuh]

On 2026-03-06 17:33:09+0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> Based on Thomas Weißschuh's series to kernel headers to no longer require
> an installed libc when build testing the uapi headers, the same can now
> be done for the scripts/check-uapi.sh script.
> 
> The only required change here is to add the  usr/dummy-include include
> path.
> 
> Link: https://lore.kernel.org/lkml/20260227-kbuild-uapi-libc-v1-0-c17de0d19776@weissschuh.net/ [1]
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  scripts/check-uapi.sh | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/scripts/check-uapi.sh b/scripts/check-uapi.sh
> index e4d120eb09e3..c8beec58871c 100755
> --- a/scripts/check-uapi.sh
> +++ b/scripts/check-uapi.sh
> @@ -191,6 +191,7 @@ do_compile() {
>  		  -fno-eliminate-unused-debug-types \
>  		  -g \
>  		  "-I${inc_dir}" \
> +		  "-Iusr/dummy-include" \

What about also using -nostdinc?

>  		  -include "$header" \
>  		  -
>  }

I have a similar (unfinished) patch flying around which also
uses usr/dummy-include from the different kernel versions
to avoid mismatches in case something gets removed there.
Not sure if it is worth it.


diff --git a/scripts/check-uapi.sh b/scripts/check-uapi.sh
index 955581735cb3..48d157ee5408 100755
--- a/scripts/check-uapi.sh
+++ b/scripts/check-uapi.sh
@@ -186,7 +186,9 @@ do_compile() {
                  -std=c90 \
                  -fno-eliminate-unused-debug-types \
                  -g \
+                 -nostdinc \
                  "-I${inc_dir}" \
+                 "-I${inc_dir}/../dummy-include" \
                  -include "$header" \
                  -
 }
@@ -197,6 +199,7 @@ run_make_headers_install() {
        local -r install_dir="$(get_header_tree "$ref")"
        make -j "$MAX_THREADS" ARCH="$ARCH" INSTALL_HDR_PATH="$install_dir" \
                headers_install > /dev/null
+       rsync -a usr/dummy-include/ "$install_dir"/dummy-include/
 }

 # Install headers for both git refs

Re: [PATCH 3/3] check-uapi: use dummy libc includes

[Arnd Bergmann]

On Fri, Mar 6, 2026, at 17:39, Thomas Weißschuh wrote:
> On 2026-03-06 17:33:09+0100, Arnd Bergmann wrote:
>>  		  -g \
>>  		  "-I${inc_dir}" \
>> +		  "-Iusr/dummy-include" \
>
> What about also using -nostdinc?

I just removed it from my version after I found it made no difference,
and I wanted to keep the changes shorter. I agree it's slightly cleaner.

> I have a similar (unfinished) patch flying around which also
> uses usr/dummy-include from the different kernel versions
> to avoid mismatches in case something gets removed there.
> Not sure if it is worth it.

Agreed, I certainly don't mind having your version either if
anyone cares enough. I suppose it would add a very small build time
overhead for the extra copy, but if it does help catch bugs it
would be worth the time.

    Arnd

Re: [PATCH 3/3] check-uapi: use dummy libc includes

[Thomas Weißschuh]

On 2026-03-06 17:45:36+0100, Arnd Bergmann wrote:
> On Fri, Mar 6, 2026, at 17:39, Thomas Weißschuh wrote:
> > On 2026-03-06 17:33:09+0100, Arnd Bergmann wrote:
> >>  		  -g \
> >>  		  "-I${inc_dir}" \
> >> +		  "-Iusr/dummy-include" \
> >
> > What about also using -nostdinc?
> 
> I just removed it from my version after I found it made no difference,
> and I wanted to keep the changes shorter. I agree it's slightly cleaner.

Ack, your choice.

> > I have a similar (unfinished) patch flying around which also
> > uses usr/dummy-include from the different kernel versions
> > to avoid mismatches in case something gets removed there.
> > Not sure if it is worth it.
> 
> Agreed, I certainly don't mind having your version either if
> anyone cares enough. I suppose it would add a very small build time
> overhead for the extra copy, but if it does help catch bugs it
> would be worth the time.

It is less about catching bugs, those will already have been caught by
the header tests before. But if something is removed from the dummy
headers because it became unused, the old UAPI headers won't build
anymore against the new dummy-headers.


Thomas

Re: [PATCH 0/3] check-uapi: improve portability for testing headers

[Nathan Chancellor]

On Fri, Mar 06, 2026 at 05:33:06PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> While working on a series to clean up some uapi headers, I needed
> to check the that the actual ABI remains unchanged. I found that
> scripts/check-uapi.sh works well enough for architectures that have a
> full toolchain installed, but not with the nolibc compilers I provide
> on kernel.org.
> 
> I ended up with a series addressing three separate issues here, but in
> the end I can now validate ABI changes across all supported architectures
> and ABIs.
> 
> The third patch depends on a series from Thomas Weißschuh that was
> just merged into the kbuild-for-next tree, the other ones could
> also apply to older kernels. I have marked the second patch for
> backports to stable kernels, this one is what caused me the most
> work in debugging.
> 
>     Arnd
> 
> Arnd Bergmann (3):
>   check-uapi: link into shared objects
>   check-uapi: honor ${CROSS_COMPILE} setting
>   check-uapi: use dummy libc includes

Acked-by: Nathan Chancellor <nathan@kernel.org>

I assume that the shared objects change does not impact catching ABI
differences?

Cheers,
Nathan

Re: [PATCH 3/3] check-uapi: use dummy libc includes

[Nicolas Schier]

Hi Arnd and Thomas,

On Sat, Mar 07, 2026 at 09:51:05AM +0100, Thomas Weißschuh wrote:
> On 2026-03-06 17:45:36+0100, Arnd Bergmann wrote:
> > On Fri, Mar 6, 2026, at 17:39, Thomas Weißschuh wrote:
> > > On 2026-03-06 17:33:09+0100, Arnd Bergmann wrote:
> > >>  		  -g \
> > >>  		  "-I${inc_dir}" \
> > >> +		  "-Iusr/dummy-include" \
> > >
> > > What about also using -nostdinc?
> > 
> > I just removed it from my version after I found it made no difference,
> > and I wanted to keep the changes shorter. I agree it's slightly cleaner.
> 
> Ack, your choice.
> 
> > > I have a similar (unfinished) patch flying around which also
> > > uses usr/dummy-include from the different kernel versions
> > > to avoid mismatches in case something gets removed there.
> > > Not sure if it is worth it.
> > 
> > Agreed, I certainly don't mind having your version either if
> > anyone cares enough. I suppose it would add a very small build time
> > overhead for the extra copy, but if it does help catch bugs it
> > would be worth the time.
> 
> It is less about catching bugs, those will already have been caught by
> the header tests before. But if something is removed from the dummy
> headers because it became unused, the old UAPI headers won't build
> anymore against the new dummy-headers.
> 
> 
> Thomas

Shall I wait some more days for a possible modified patch 3/3?
Otherwise I'd like to apply the series to kbuild-next-unstable.  

Thanks and kind regards,
Nicolas

Re: [PATCH 3/3] check-uapi: use dummy libc includes

[Thomas Weißschuh]

On 2026-03-20 21:12:53+0100, Nicolas Schier wrote:
> On Sat, Mar 07, 2026 at 09:51:05AM +0100, Thomas Weißschuh wrote:
> > On 2026-03-06 17:45:36+0100, Arnd Bergmann wrote:
> > > On Fri, Mar 6, 2026, at 17:39, Thomas Weißschuh wrote:
> > > > On 2026-03-06 17:33:09+0100, Arnd Bergmann wrote:
> > > >>  		  -g \
> > > >>  		  "-I${inc_dir}" \
> > > >> +		  "-Iusr/dummy-include" \
> > > >
> > > > What about also using -nostdinc?
> > > 
> > > I just removed it from my version after I found it made no difference,
> > > and I wanted to keep the changes shorter. I agree it's slightly cleaner.
> > 
> > Ack, your choice.
> > 
> > > > I have a similar (unfinished) patch flying around which also
> > > > uses usr/dummy-include from the different kernel versions
> > > > to avoid mismatches in case something gets removed there.
> > > > Not sure if it is worth it.
> > > 
> > > Agreed, I certainly don't mind having your version either if
> > > anyone cares enough. I suppose it would add a very small build time
> > > overhead for the extra copy, but if it does help catch bugs it
> > > would be worth the time.
> > 
> > It is less about catching bugs, those will already have been caught by
> > the header tests before. But if something is removed from the dummy
> > headers because it became unused, the old UAPI headers won't build
> > anymore against the new dummy-headers.

> Shall I wait some more days for a possible modified patch 3/3?
> Otherwise I'd like to apply the series to kbuild-next-unstable.  

It is a somewhat theoretical issue and if it arises at some point we can
still fix it up. So this shouldn't block the patches.

For the series:

Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>


Thomas

Re: [PATCH 3/3] check-uapi: use dummy libc includes

[Nicolas Schier]

On Fri, Mar 20, 2026 at 09:31:07PM +0100, Thomas Weißschuh wrote:
> On 2026-03-20 21:12:53+0100, Nicolas Schier wrote:
> > On Sat, Mar 07, 2026 at 09:51:05AM +0100, Thomas Weißschuh wrote:
> > > On 2026-03-06 17:45:36+0100, Arnd Bergmann wrote:
> > > > On Fri, Mar 6, 2026, at 17:39, Thomas Weißschuh wrote:
> > > > > On 2026-03-06 17:33:09+0100, Arnd Bergmann wrote:
> > > > >>  		  -g \
> > > > >>  		  "-I${inc_dir}" \
> > > > >> +		  "-Iusr/dummy-include" \
> > > > >
> > > > > What about also using -nostdinc?
> > > > 
> > > > I just removed it from my version after I found it made no difference,
> > > > and I wanted to keep the changes shorter. I agree it's slightly cleaner.
> > > 
> > > Ack, your choice.
> > > 
> > > > > I have a similar (unfinished) patch flying around which also
> > > > > uses usr/dummy-include from the different kernel versions
> > > > > to avoid mismatches in case something gets removed there.
> > > > > Not sure if it is worth it.
> > > > 
> > > > Agreed, I certainly don't mind having your version either if
> > > > anyone cares enough. I suppose it would add a very small build time
> > > > overhead for the extra copy, but if it does help catch bugs it
> > > > would be worth the time.
> > > 
> > > It is less about catching bugs, those will already have been caught by
> > > the header tests before. But if something is removed from the dummy
> > > headers because it became unused, the old UAPI headers won't build
> > > anymore against the new dummy-headers.
> 
> > Shall I wait some more days for a possible modified patch 3/3?
> > Otherwise I'd like to apply the series to kbuild-next-unstable.  
> 
> It is a somewhat theoretical issue and if it arises at some point we can
> still fix it up. So this shouldn't block the patches.
> 
> For the series:
> 
> Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
> 
> 
> Thomas

ok, thanks!

-- 
Nicolas

Re: [PATCH 0/3] check-uapi: improve portability for testing headers

[Nicolas Schier]

On Fri, 06 Mar 2026 17:33:06 +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> While working on a series to clean up some uapi headers, I needed
> to check the that the actual ABI remains unchanged. I found that
> scripts/check-uapi.sh works well enough for architectures that have a
> full toolchain installed, but not with the nolibc compilers I provide
> on kernel.org.
> 
> [...]

Applied to kbuild/linux.git (kbuild-next-unstable), thanks!

[1/3] check-uapi: link into shared objects
      https://git.kernel.org/kbuild/c/a261f6df
[2/3] check-uapi: honor ${CROSS_COMPILE} setting
      https://git.kernel.org/kbuild/c/9940ec38
[3/3] check-uapi: use dummy libc includes
      https://git.kernel.org/kbuild/c/bb25b563

Please look out for regression or issue reports or other follow up
comments, as they may result in the patch/series getting dropped,
reverted or modified (e.g. trailers). Patches applied to the
kbuild-next-unstable branch are accepted pending wider testing in
linux-next and any post-commit review; they will generally be moved
to the kbuild-next branch in about a week if no issues are found.

Best regards,
-- 
Nicolas