Port-m68k archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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 <arnd%arndb.de@localhost> wrote:
> On Tue, Jan 6, 2026, at 14:40, John Paul Adrian Glaubitz wrote:
> > On Tue, 2026-01-06 at 14:34 +0100, Kolbjørn 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 the
> >> gcc provided fails building kernel, stopping at arch/m68k/kernel/signal.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=padded 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=padded]
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=c90 (equivalent to -ansi) catches the violation of those.
> # We cannot go as far as adding -Wpedantic since it emits too many warnings.
> -UAPI_CFLAGS := -std=c90 -Werror=implicit-function-declaration
> +UAPI_CFLAGS := -std=c90 -Werror=implicit-function-declaration -Werror=padded
> +
> +# when cross-compiling with a minimal toolchain, use nolibc headers
> +UAPI_CFLAGS += -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:17,
from <command-line>:
/usr/m68k-linux-gnu/include/bits/types/struct_iovec.h:26:8: error:
redefinition of ‘struct iovec’
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 ‘__socklen_t’
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
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert%linux-m68k.org@localhost
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Home |
Main Index |
Thread Index |
Old Index