[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: