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