Hi, On Mon, 2025-06-23 at 01:13 +0300, Eero Tamminen wrote: > 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)?
Not sure why this would be required? I don't expect anyone to download m68k 2 byte binaries to install and try to run them on a 4 bytes system. > > - 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 I will check whether the kernel performs any checks on the ELF format on modules. > - Full test-suites run also for other important projects which e.g. > include m68k / CF asm code As I have already said, I am working on rebuilding the full archive with 4 bytes alignment and I have already built an initial set of packages without problems. I will set up a local wanna-build and MiniDAK instance next to automate the rest of the package building. > - Changes tested to work as expected _both_ with 2- and 4-byte alignment > builds The 2 bytes alignment port will be abandoned in Debian anyway, so I expect to eventually stop working without me constantly testing it > 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... That's my main argument the whole time: There is no value in running old Debian binaries on m68k as we have the source for everything and can just rebuild packages. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
