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,
>
> On Mon, 16 Jun 2025 at 14:21, John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> wrote:
> > I wrote that message on Friday. Odd that your email client claims it was sent today.
> > Besides that, I would like to point again at what John Klos wrote in reply to Finn [1].
>
> 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 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)
- NetBSD uses an emulation layer which allows 2 bytes alignment a.out executables 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 check for regressions
Anything else I'm missing?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: