Re: Preliminary results - was: Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k
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
Reply to: