On Mon, 16 Jun 2025, John Paul Adrian Glaubitz wrote:could be
To summarize:
- the ELF header provides provides the e_ident and e_flags fields which
ABIused for identifying a Linux/m68k system using the 4 bytes alignment
(SysV ABI)- MIPS uses e_flags for differentiating its ABIs
- PA-RISC sets e_ident to 0x03 (Linux) while every other arch uses 0x00
lude/user/abitypes.h)- qemu-user needs to be patched to deal with the changed alignment (inc
ch/m68k/kernel/signal.c)- the kernel needs to be patched to deal with the changed alignment (ar
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
To summarize:
- the ELF header provides provides the e_ident and e_flags fields which could be
used for identifying a Linux/m68k system using the 4 bytes alignment ABI
- MIPS uses e_flags for differentiating its ABIs
- PA-RISC sets e_ident to 0x03 (Linux) while every other arch uses 0x00 (SysV ABI)
- qemu-user needs to be patched to deal with the changed alignment (include/user/abitypes.h)
- the kernel needs to be patched to deal with the changed alignment (arch/m68k/kernel/signal.c)
Hi Kolbj?rn,ch could be
On Tue, 2026-01-06 at 14:34 +0100, Kolbj?rn Barmen wrote:
On Mon, 16 Jun 2025, John Paul Adrian Glaubitz wrote:
To summarize:
- the ELF header provides provides the e_ident and e_flags fields whi
t ABIused for identifying a Linux/m68k system using the 4 bytes alignmen
00 (SysV ABI)- MIPS uses e_flags for differentiating its ABIs
- PA-RISC sets e_ident to 0x03 (Linux) while every other arch uses 0x
nclude/user/abitypes.h)- qemu-user needs to be patched to deal with the changed alignment (i
arch/m68k/kernel/signal.c)- the kernel needs to be patched to deal with the changed alignment (
.cDoes 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
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.at would allow the kernel
According to Geert, Arnd Bergmann made some changes to the kernel uapi th
to be built with either alignment. Not sure what the current state of things is.
Let's CC Arnd to find out.
[1] https://wiki.debian.org/M68k/Alignment
On Tue, Jan 6, 2026, at 14:40, John Paul Adrian Glaubitz wrote:he
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 t
al.cgcc provided fails building kernel, stopping at arch/m68k/kernel/sign
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.
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.
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 5 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 22:23:26 |
| Calls: | 117 |
| Calls today: | 117 |
| Files: | 367 |
| D/L today: |
560 files (257M bytes) |
| Messages: | 70,893 |
| Posted today: | 26 |