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

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: