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

Hi Geert,

On Mon, 2025-06-16 at 14:29 +0200, Geert Uytterhoeven wrote:
> Hi Adrian,
>=20
> On Mon, 16 Jun 2025 at 14:21, John Paul Adrian Glaubitz
> <[email protected]> wrote:
> > I wrote that message on Friday. Odd that your email client claims it wa=
s sent today.
> > Besides that, I would like to point again at what John Klos wrote in re=
ply to Finn [1].
>=20
> The increased email traffic during the Linux kernel merge window
> causes lots of delayed email :-(

Hmm, I see. Let's cool this discussion down a bit and summarize what we got=
 so far:

To summarize:

- the ELF header provides provides the e_ident and e_flags fields which cou=
ld 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 (Sy=
sV 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/m=
68k/kernel/signal.c)
- NetBSD uses an emulation layer which allows 2 bytes alignment a.out execu=
tables on an
  ELF system with 4 bytes alignment
- glibc needs to be patched in sysdeps/m68k/utmp-size.h
- gcc needs to be patched in gcc/config/m68k/linux.h (BIGGEST_ALIGNMENT to =
64, EMPTY_FIELD_BOUNDARY
  and STACK_BOUNDARY to 32, see netbsd-elf.h)
- the glibc and gcc testsuites should be run in a 4 bytes alignment to chec=
k for regressions

Anything else I'm missing?

Adrian

--=20
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913