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

Eero Tamminen <[email protected]> Mon, 23 Jun 2025 01:13:08 +0300
Newsgroups gmane.os.netbsd.ports.m68k,gmane.linux.debian.ports.68k,gmane.linux.ports.m68k
Message-ID <[email protected]>
Hi,

On 16.6.2025 18.39, John Paul Adrian Glaubitz wrote:
> 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

So Linux could eventually have similar emulation layer for 2-byte 
aligned ELF binaries (I don't see point in a.out support)?

> - 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?

- ELF loaders for kernel, its modules and user-space need to be patched 
to reject ELF binaries with wrong ELF flags
- Full test-suites run also for other important projects which e.g. 
include m68k / CF asm code
- Changes tested to work as expected _both_ with 2- and 4-byte alignment 
builds
?


On 18.6.2025 15.27, John Paul Adrian Glaubitz wrote:
 > On Wed, 2025-06-18 at 22:21 +1000, Greg Ungerer wrote:
 >> The bulk of the instruction set is the same. Asm code will look totally
 >> familiar to anyone who knows m68k :-)   One notable difference is that
 >> there is a more limited set addressing modes for some instructions.
 >
 > True, but you won't be able to run any classic m68k binaries on ColdFire
 > and the other way around, are you?

Besides binaries that use just the common instruction subset between 
m68k / CF, the individual m68k instructions can be emulated, or whole 
program can be run under m68k emulation (something more light-weight 
than user-qemu).  See e.g. ACP:
https://en.wikipedia.org/wiki/Atari_Coldfire_Project#Compatibility

It all depends on how much there's value in running older binaries which 
have no sources available, or haven't been rebuild for some other 
reason.  On ACP there was more reason than on Debian...


	- Eero