Re: Preliminary results - was: Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

Hi Arnd,

On Tue, 6 Jan 2026 at 16:38, Arnd Bergmann <[email protected]> wrote:
> On Tue, Jan 6, 2026, at 14:40, John Paul Adrian Glaubitz wrote:
> > On Tue, 2026-01-06 at 14:34 +0100, Kolbj=C3=B8rn Barmen wrote:
> >> On Mon, 16 Jun 2025, John Paul Adrian Glaubitz wrote:
> >>
> >> Does this patch exist somewhere? I ask because I am migrating to
> >> 32bit-aligned userland (https://www.gentoo.org/downloads/#m68k) and th=
e
> >> gcc provided fails building kernel, stopping at arch/m68k/kernel/signa=
l.c
> >
> > I haven't created that patch yet as my work on this effort is currently
> > paused. However, it should
> > be straight-forward to update the asserts in the kernel code.
> >
> > According to Geert, Arnd Bergmann made some changes to the kernel uapi
> > that would allow the kernel
> > to be built with either alignment. Not sure what the current state of
> > things is.
> >
> > Let's CC Arnd to find out.
>
> Hi Adrian,
>
> I have these patches in my work-in-progress tree, and I still
> plan to submit them upstream, but haven't made any progress on
> it since I talked to Geert about it last month.
>
> See below for my current working version against roughly v6.18,
> which replaces all the implicit padding in uapi header files
> with explicit padding.
>
> What I do here is a combination of changes:
>
>  - add -Werror=3Dpadded to the header checks to catch any
>    implicit padding on any architecture
>  - add __uapi_arch_pad8 for any 8-bit pad that is the
>    same on any architecture
>  - add __uapi_arch_pad16 for any 16-bit pad that is the
>    same on any architecture other than m68k
>  - add __uapi_arch_pad32 for any 32-bit pad for
>    padding between __u32 and __u64 on all architectures
>    that naturally align __u64
>  - add __uapi_arch_pad_long between __u32 and long
>    (or pointer) on 64-bit architectures
>  - a few more specialized macros for less common corner
>    cases
>  - annotate structures as __uapi_arch_align to force 16-bit
>    alignment on m68k and larger alignment elsewhere,
>    regardless of -malign-int
>
> I've tested this by running the header check on all
> architectures, and running the abigail tests to ensure
> the ABI is unmodified (abigail is currently broken on a
> few architectures).
>
> With all the patches applied, we get two benefits:
>  - m68k kernels have a consistent ABI with and without
>    -malign-int, so kernel and userspace can use
>    different setting here, and we can eventually change
>    the kernel to always use -malign-int
>  - Any new patches that introduce implicit padding in the
>    uapi headers break the build and get fixed before they
>    cause problems. Almost all the instances I've seen
>    are unintentional.
>
> I have started splitting up the change into individual
> commits that explain the padding, but it will take more
> work to get through the entire patch, plus any additional
> changes for review comments.
>
>
> The diffstat is
>
>  407 files changed, 2433 insertions(+), 754 deletions(-)
>
> and I think this touches around 1500 structures, though
> most files only have a single one.

Thanks, this seems to work fine for atari_defconfig, and generates
the exact same code as before.

However, m68k allmodconfig fails with:

    In file included from tools/include/nolibc/nolibc.h:97,
                     from tools/include/nolibc/stddef.h:8,
                     from ./usr/include/scsi/fc/fc_els.h:14,
                     from <command-line>:
    tools/include/nolibc/types.h:120:1: error: padding struct size to
alignment boundary with 1 bytes [-Werror=3Dpadded]
      120 | };
          | ^
    cc1: all warnings being treated as errors
    make[4]: *** [usr/include/Makefile:85:
usr/include/scsi/fc/fc_els.hdrtest] Error 1

This is due to struct linux_dirent64 in tools/include/nolibc/types.h.
The same definition in include/linux/dirent.h doesn't cause issues.

> --- a/usr/include/Makefile
> +++ b/usr/include/Makefile
> @@ -6,7 +6,10 @@
>  #
>  # -std=3Dc90 (equivalent to -ansi) catches the violation of those.
>  # We cannot go as far as adding -Wpedantic since it emits too many warni=
ngs.
> -UAPI_CFLAGS :=3D -std=3Dc90 -Werror=3Dimplicit-function-declaration
> +UAPI_CFLAGS :=3D -std=3Dc90 -Werror=3Dimplicit-function-declaration -Wer=
ror=3Dpadded
> +
> +# when cross-compiling with a minimal toolchain, use nolibc headers
> +UAPI_CFLAGS +=3D -I$(srctree)/tools/include/nolibc/

Without the rest of the patch, this line on its own is already causing
various allmodconfig failures for me:

    In file included from /usr/m68k-linux-gnu/include/sys/socket.h:26,
                     from usr/include/linux/if.h:28,
                     from ./usr/include/linux/netfilter_bridge/ebtables.h:1=
7,
                     from <command-line>:
    /usr/m68k-linux-gnu/include/bits/types/struct_iovec.h:26:8: error:
redefinition of =E2=80=98struct iovec=E2=80=99
       26 | struct iovec
          |        ^~~~~
    In file included from tools/include/nolibc/sys/uio.h:15,
                     from tools/include/nolibc/nolibc.h:113,
                     from tools/include/nolibc/stddef.h:8,
                     from
/usr/m68k-linux-gnu/include/bits/types/struct_iovec.h:23:
    usr/include/linux/uio.h:17:8: note: originally defined here
       17 | struct iovec
          |        ^~~~~
    In file included from /usr/m68k-linux-gnu/include/sys/socket.h:33:
    /usr/m68k-linux-gnu/include/bits/socket.h:33:9: error: unknown
type name =E2=80=98__socklen_t=E2=80=99
       33 | typedef __socklen_t socklen_t;
          |         ^~~~~~~~~~~
      HDRTEST usr/include/linux/tc_act/tc_mirred.h
    make[4]: *** [usr/include/Makefile:85:
usr/include/linux/netfilter_bridge/ebtables.hdrtest] Error 1
      HDRTEST usr/include/linux/tc_act/tc_connmark.h

I guess that is due to having libc6-dev-m68k-cross installed.

Dropping this line made the linux_dirent64 issue go away, and revealed
a few more missing pieces, so here is a gmail-whitespace-damaged patch:

diff --git a/include/uapi/linux/xfrm.h b/include/uapi/linux/xfrm.h
index 70eece6aa30e9306..4c10f5402d77757d 100644
--- a/include/uapi/linux/xfrm.h
+++ b/include/uapi/linux/xfrm.h
@@ -27,7 +27,9 @@ struct xfrm_id {
        xfrm_address_t  daddr;
        __be32          spi;
        __u8            proto;
-};
+       __uapi_arch_pad8;
+       __uapi_arch_pad16;
+} __uapi_arch_align;

 struct xfrm_sec_ctx {
        __u8    ctx_doi;
@@ -255,6 +257,7 @@ struct xfrm_user_tmpl {
        __u8                    mode;
        __u8                    share;
        __u8                    optional;
+       __uapi_arch_pad8;
        __u32                   aalgos;
        __u32                   ealgos;
        __u32                   calgos;

Gr{oetje,eeting}s,

                        Geert

--=20
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org

In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
                                -- Linus Torvalds